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ABSTRACT 


Development of SeaBase Operations has brought about the need 
for Modeling and Simulation (M&S) analysis of prototypes 
like the Transformable Craft (T-craft) as a SeaBase Enablers 
(SBE) . The uses of M&S tools for the modeling of new 
capabilities have been problematic, since there are no 
standard requirements for simulation development. The 
accreditation process of M&S tools also offers no guidance 
into the functionalities of simulations. The goal of this 
thesis was to define a hierarchical framework of 
capabilities for evaluating a simulation or "suite of 
simulations" suitable for modeling SBEs. A capability 
hierarchy is needed to enable decision makers to compare end 
user needs with M&S tools' abilities. An analysis of 
alternatives was conducted on six M&S tools to develop a 
capability hierarchy. The three top level capabilities that 
were defined in an M&S setting were Usability, Flexibility, 
and Scalability . A roll-up method was then used to evaluate 
three time-step and three next-event based models. The end 
result of the comparisons showed that a "suite of 
simulations" was more capable of modeling SBEs than a single 
simulation. The results provide decision makers with a 
standard approach to define user needs and how to apply them 
to M&S tools. 
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I. 


INTRODUCTION 


All models are wrong, but some are useful 

—Sergey Arkhipenkov 

A. BACKGROUND 

Modeling and Simulation (M&S) tools typically have been 
designed for specific purposes but often are used for 
insight into completely different questions. In today's 
technologically advanced world, there has been relatively no 
limit to the capability of computer-based simulation and 
what it could provide to understanding an event. 

This study focused on the capabilities of M&S tools to 
represent SeaBase Enablers (SBE) by conducting an analysis 
of alternatives of computer-based simulations. The context 
of this study was based on SeaBase Operations (SBO) concept, 
being developed by the United States Navy, which extends 
from a concept called Sea Power 21 that advertises power 
from the sea. Seapower is the concept of globally 
projecting naval presence to maintain security and advancing 
the national interests (CNO, 2007). Facilitating these 
naval operations at sea is a complex naval organization that 
relies heavily on logistical support ships necessary for 
sustainment. The SBE concept was defined as the logistical 
support elements that interact with the SBO to provide cargo 
and supplies for sustainment operations. 

The models chosen were time-step and next-event based 
models, which are two types of models within the 
constructive category of M&S. A narrow scope of Department 
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of Defense (DoD) and industrial used models that have had 
application in SBE modeling are listed in Table 1. 


Model Common Name 

Simulation Category 

Integrated Theater Engagement Model 

(ITEM) 

Defense Threat Reduction Agency in 

association with (IAW) SAIC Company 

/ Next-Event 

Naval Simulation System (NSS) 

SPAWAR IAW Metron Co. / Next-Event 

Map Aware Non-Uniform Automata 

(MANA) 

New Zealand's Defense Technology 

Agency / Time-Step 

Pythagoras 

Marine Corps Warfighting Lab (MCWL) 

IAW Northrop Grumman / Time-Step 

Joint Conflict and Tactical 

Simulation (JCATS) 

Joint Force Command (JFCOM) Joint 

Warfare Center (JWC) / Next-Event 

Simkit 

Naval Postgraduate School / Next- 

Event 

EXTENDSim 

Imagine That! / Next-Event 

Combat Analysis Tool for the 21 st 

Century (COMABT XXI) 

TRAC WSMR IAW MCCDC OAD / Next- 

Event 

SimPy 

Source Forge Co. / Next-Event 

NetLOGO 

Connected Mathematics Co. / Next- 

Event 


Table 1. M&S Tools Used in DoD and Industry for SBE 

Modeling. 


Current modeling of the SBE is use of NSS by the System 
Engineering Group at the Naval Postgraduate School (NPS) to 
model SBE in peacekeeping, crisis, and stability missions. 
SimPy is another M&S tool being used by Georgia Tech 
University to model SeaBase concepts and determine 
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alternative employment of SBE for scenarios around the world 
when based at different debarkation points. 


B. SEAPOWER 21 

The Strategy for Sea Power 21 entails joint operational 
effectiveness and incorporates SBO and Sea Shield operations 
(Projecting Global Defensive Assurance) to make a unified 
front called Sea Strike (Projecting Precise and Persistent 
Offensive Power) with new technology that must be ready to 
support it. The Chief of Naval Operations (CNO) (2007) has 
stated that the Navy must maintain an ability that will 
reaffirm "the use of sea power to influence actions and 
activities at sea and ashore" (p. 8) . Thus, operational 

focus of the U.S. Navy has shifted from traditional warfare 
to developing SeaBase concepts and sustained operations in 
forward deployed areas. SBO is one of the strategic pillars 
supporting operations in a Naval setting, with Sea Power 21 
being the conceptual wave of the future. Sea Power 21 is 
derived from the unified maritime strategy of the CNO to 
protect the American way of life. It is the ability of the 
U.S. Navy to be globally postured around the world to 
maintain continued operations with adequate resources. This 
includes pre-positioned capabilities, joint operations, and 
decreased reliance on infrastructure (Flitter & Sintic, 
2009) . The SBO establishes a base of operations for U.S. 
military forces to be inserted into the conflict or crisis 
(CNO, 2007). 

SBO enables National and Naval strategy with the 

ability to maintain operational sustainment. SBO roles in 

crisis relief efforts and regional conflict have evolved 

with the ever changing demands of the world. Contributions 
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to allied nations have been closely linked to the ability to 
maintain the sea lanes of communication. Relief efforts in 
crisis-stricken countries like India in 2007, Aceh Indonesia 
and Sri Lanka in 2008, Thailand in 2008, and most recently, 
Haiti in 2010, have shown the versatility of the U.S. Navy 
and the U.S. military to perform operations other than 
warfare. The U.S. government has made it a priority to make 
humanitarian and relief operations just as important as 
warfare operations. 

According to the Office of the Under Secretary of 
Defense for Acquisition, Technology, and Logistics 
(USDAT&L), SBO are enablers of Sea Power 21 (CNO, 2007) . 
SBO require development of new capabilities to enable its 
use in the 21st century. SBO is a chain of interdependent 
operations that have systematic issues with current 
capabilities for sustainment. The recommended capability 
for development is for a long-range heavy-lift cargo vessel 
that is able to handle environmental conditions. Through 
industrial and academia research, the SBE is being formed 
into that capability with the focus being to fill current 
technology gaps. 

C. SEABASE ENABLER PROTOTYPES 


One way of maintaining seapower is through research and 
development of new technologies in naval ships that can 
serve as SBE. SBEs are projected to provide rapid 
transportation of needed cargo and materials to and from the 
SeaBase to debarkation point. The Office of Naval Research 
(ONR) began the Innovative Naval Prototype (INP) program in 
2006 to refine conceptual ideas, develop technology, and 


ultimately manufacture SBE 
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Military 


capabilities. 



industrial companies have been designing a new amphibious 
craft called the Transformable Craft (T-Craft) to meet the 
SBE needs. 

There are three prototype designs in competition for 
contract awards by ONR. The first design is the Alion, 
which is being developed by Raytheon in conjunction with 
Nichols Bros and CDI Marine. The second design is Textron 
Marine, being developed by CDI Marine with Naval Surface 
Warfare Center Panama City Division, Jacobs Engineering, 
Littoral Research Group, and Mid-City New Orleans (MiNO) 
Marine Inc. The third design is the Umoe Mandal, designed 
by the Goodrich EPP in association with Kiewit Offshore 
Services, Island Engineering, General Atomics, Ultra Poly 
Inc., Griffon Hovercraft Group, Applica Inc., and 
Massachusetts Institute of Technology (MIT) (Flitter & 
Sintic, 2009). 

1. Transformable Craft 

The T-craft is an amphibious craft being designed to 
fill the technology capabilities gap in SBO and server as a 
SBE. There are technical challenges associated with 
developing prototypes of this design: minimal manning versus 
operational requirement, multi-mode propulsion systems, 
external seals for bow and stern and retractable hover 
shirts. Along with technical issues, there are operational 
considerations that are focused on placing T-craft 
capabilities in future operations. The real question is 
where will T-craft fit into the U.S. military's concept of 
operations? The initial deployment vision is centered on 


5 



worldwide fast response to crisis missions, followed by 
combat supply missions. Further details on T-craft missions 
will be explored in Chapter V. 

2. Industrial Designs 

The T-craft prototype designs are based on ONR 
capability requirements with only slight differences. The 
Textron Marine is projected to have an open bay deck, unlike 
the other two prototypes, which have closed bays. Deck 
space varies, with the Umoe Mandal having 6000 feet (ft) 2 to 
the Textron Marine having 8000 square feet (ft) 2 . One 
important capability consideration with the development of 
T-craft is the limitation on landing abilities. T-craft 
hover capability is projected to be able to maneuver onto 
shore slopes with gradients of approximately 2 percent or 
less. All M&S tools were assumed to model shore landing 
site with less than 2 percent slopes and be sufficient for 
SBE Scenarios. Figure 1 depicts the three T-craft 
prototypes. 
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Figure 1. 


3. 


Initial T-Craft Analysis 


A capstone project conducted by a group of Systems 
Engineering students at NPS working in conjunction with ONR 
sponsored funding investigated whether the T-craft prototype 
was a suitable SBE. Their research performed a simplified 
Analysis of Alternatives on the SBE concept. Their results 
identified key stake holders that contributed to the 
validation of the capabilities for SBE. Additionally, these 
students provided insight to decision makers on transport 
capabilities and benefits to the SeaBase. Lastly, their 
project gave technical recommendations to ONR on where the 
T-craft program should proceed (Flitter & Sintic, 2009) . 

D. T-CRAFT DEVELOPMENT 

T-craft is being designed to fill the gaps in current 
SBE capabilities. ONR defined capabilities for the T-craft 
are: 

1. 2500 nm range maintaining fuel efficiency (20kts). 

2. Operate in sea state of 4 at high speeds, with or 
without cargo. 

3. Maintain a maximum speed of 40+ knots and a 500 nm 
combat range. 

4. Amphibious mode for landing on the beach. 

5. Freely convert between modes at sea. 

6. Transfer cargo to SBO units and beach landings 
sites. 

7. Carry 500 Long Tons (LT) of Cargo (ONR, 2005). 
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ONR (2005) began developing the T-craft "Game Changing" 
capability with the issuance of the Broad Agency 
Announcement (BAA) 05-020 and a call for an INP for SBE 
operations. The ideal use for T-craft is in a high-speed 
sealift scenario less than 300 nautical miles (nm) from the 
shore in no more than sea state 4 and with a payload of 500 
long tons. BAA focused on industrial competition of 
designing T-craft with the ultimate desire to acquire a 
material solution to current gaps in SBE. In each Phase of 
development, ONR has pointed out the need to use M&S tools 
in analysis and evaluation of T-craft capabilities in a cost 
reduction effort. The final goal is to develop the concept, 
build, test, and demonstrate the concept's ability in given 
scenario settings. 

There are four scenario requirements for which T-craft 
is being developed: Peacekeeping and Peace Enforcement, 
Regional Crisis Intervention, Security and Stability 
Operations, and Major Theater War. These requirements were 
the basis for scenario development in this study. The 
scenarios were based on a possible North Korean threat to 
the South Korea peninsula. The area of SBOs was based in 
the Sea of Japan regional layout. The geography allowed for 
a logistic hub to be within 2500 nm of the SBO and that 
could vary in distance from the shore line. The scenario 
was designed with two phases: Basic and Advanced. The Basic 
Scenario was a non-opposed scenario similar to a regional 
crisis intervention. The Advanced Scenario added onto the 
Basic Scenario hostile and escort forces in the SBO area. 
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E. MODELING & SIMULATION 

This research focused on M&S tools' ability to allow 
for visualization and comprehension of the SBE Scenario. 
The Validation, Verification, & Accreditation (W&A) process 
requires that M&S tools be analyzed for correctness and 
usefulness. This process will be described in Chapter II. 
Further research could be conducted to determine the general 
capabilities of a Federate of simulations for modeling of a 
SBE concept. The subjective analysis of a group of 
simulations for SBE Scenario was the main objective of this 
thesis. 

There are seven M&S Domains that cover M&S within the 
DoD. In this thesis, four domains were used to define the 
capabilities of a simulation of the SBE: Acquisition, 
Planning, Test & Evaluation, and Analysis. The advantage of 
using these domain fields was to narrow the scope of the M&S 
Domain space for developing technology like the SBE. The 
three capabilities that can be derived from these domains 
are usability, flexibility, and scalability. These 
capabilities were designed to ultimately provide decision 
makers with adequate information on M&S tools to apply 
throughout the life cycle of the SBE. Constructive-based 
M&S tools are poised for the development of scenarios to 
enable analysis with time-step and next-event based models. 

1. DoD M&S Community Domains 

The goal of this thesis was to define the needs of SBE 
as they apply to M&S. A capability hierarchy framework was 
used to translate the SBE needs into listing of 
functionalities for a simulation or a "suite of simulations" 
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to be evaluated. The purpose was to apply the framework 
broadly across the M&S solution trade space for SBE 
modeling. Ultimately, the Systems Engineering approach used 
was to define a process to evaluate the contribution 
simulations may have on SBE. 

There are seven domains in M&S: Acquisition, Analysis, 
Planning, Testing, Training, Experimentation, and 
intelligence. These domains are a way for the DoD to manage 
and shape M&S tools for practical use. Below, the first 
four domains and how each pertains to the SBE are defined. 
The last three domains were not discussed in this thesis 
because the scope was to address M&S tools that contribute 
to the development of an INP. Training, Experimentation and 
Intelligence pertain to operational considerations and post 
production (DoD, 2009). 

First, Acquisition is the overall process of material 
solutions in the cumulative joint capabilities of the U.S. 
military. There are two options in acquisition: (1) 
Material solutions, which are the development of new 
technologies for capability gaps, and (2) Documentation 
solutions, which are the development of doctrine to adjust 
for operational deficiencies. M&S can provide assistance in 
the development of a SBE throughout the T-craft life cycle 
(DoD, 2009) . 

Second, Analysis is the ability to understand how a 
process or situations potentially unfolds in the future. In 
other words. Analysis can provide proof of concepts for SBO 
in forward deployed areas. M&S gives researchers the 
ability to model operational considerations in an effort to 
develop systems with well rounded capabilities (DoD, 2009) . 
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Third, Planning is a stage for developing systems 
tactics and strategy for use in military operations. The 
SBE is new concept that is going through extensive research 
in interoperability and capability limitations. Planning 
can identify key performance parameters in a SBE by 
examining situational reguirements (DoD, 2009) . 

Fourth, Testing is the opportunity to stress systems in 
virtual and real environments to give the warfighters 
advanced capabilities. M&S can stress systems to the 
maximum limits in a virtual environment allowing for a 
spectrum of information to be gathered (DoD, 2009). 


2. M&S Capabilities Derivation 

The M&S domains described above encompass three aspects 
that a simulation should possess to model a SBE, and these 
are Usability, Flexibility, and Scalability. Usability 
seems to relate to interoperability issues in a joint 
environment where new technology must be able to interact 
and/or support other service functions. Flexibility seems 
to directly reflect the versatility of new technology to 
evolve and be sustainable in an ever changing environment. 
Scalability seems to be associated with realistic goals of 
mass production and survivability in multiple environments. 

3. Simulation Categories 

There are several types of simulation that are used for 
modeling and analysis. The three M&S types that were 
associated with this study were next-event, time-step, and 
autonomous agent-based modeling. Time-step based models use 
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equal time-steps between processing functions of events to 
advance the simulation. Next-event based models process 
each event in a scenario that occurs with no regard to a 
regular review of simulation status. Agent-based models are 
centered on offering attribute adjusted abilities to the 
user for more robust actions. 

These three types of M&S tools were examined across the 
SBE missions. The first of those missions entail high-level 
operational missions like peace keeping and were utilized 
for modeling a Basic Scenario. The Basic Scenario involved 
relief efforts of transporting humanitarian aid directly to 
shore sites. The second mission was regional conflict 
within hostile waters surrounding areas of SBO, which were 
used to model an Advanced Scenario. 

Evaluation of M&S tools in time-step and next-event 
based modeling assisted in determining the capability 
hierarchy. Time-step and next-event based models are key 
types of M&S tools in the constructive simulation category 
that are used in the DoD. Table 2 presents the flow of this 
thesis from capability generations to determining a trade 
space of alternatives for a simulation or "suite of 
simulations" for SBE M&S. The M&S tools for this research 
are delineated in Chapter III. 
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Chapter Title 

I Introduction into SeaBase Enablers 

II Capabilities Generation based on M&S Domains 

III Possible Solutions for M&S of SBE Scenarios 

IV Capability Hierarchy definition 

V Simulation Modeling of the SBE 

VI Results Analysis of M&S 

VII Capability Evaluation of M&S tools 
VIII Simulation Comparison of M&S tools 

IX Conclusion 


Table 2. 


Thesis Chapters Summary. 





THIS PAGE INTENTIONALLY LEFT BLANK 


14 



II. CAPABILITIES GENERATION 


The concept of defining a set of capabilities for M&S 
programs evolved from the idea of using several modeling 
tools together for SBE analysis and testing. The questions 
became, which M&S tools were to be used and what 
capabilities should they possess? It was clear that any M&S 
tool used in this research must be accredited to show that 
results from SBE analysis were valid. This lead to the DoD 
acquisition system that offers the most insight into M&S 
capabilities based on the fact that there are seven M&S 
domains created to shape the development of M&S tools. This 
chapter addresses how the capability hierarchy was generated 
from the established M&S domains areas and their uses to 
define a basic set of functionalities that were later 
complied together in a framework to evaluate the capability 
of an M&S tool. 

A. VALIDATION, VERIFICATION, & ACCREDITATION 

Use of M&S in DoD is regulated by the W&A process. 
Decision making agencies like the Defense Planning and Joint 
Requirements Oversight Council (JROC) utilize M&S for 
specific purposes based on M&S tools capabilities. 
Currently, there is not a standard for all simulations 
because W&A requirements limit on the scope of models to a 
single or narrow purpose (DoD, 2003). The capabilities 
hierarchy can allow for M&S developers working with SBE to 
be aware of user (DoD) needs and provide more functionality 
in M&S tools. 
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Developing simulation standards is important because of 
the impact M&S has at all levels of DoD decision making in 
the life cycle. The capability hierarchy that was proposed 
in this study attempted to identify standards needed to 
model SBE by grouping a set of functionalities together in 
an evaluation hierarchy. Functionality refers to a single 
method within an M&S tool that is used to enable the user to 
manipulate the model or simulation. The definition of a 
hierarchy was an attempt to increase the reusability of M&S 
tools while simultaneously reducing ad hoc program 
combinations that are being used to fill gaps in DoD M&S. 
The capability hierarchy can allow for M&S developers 
working with SBE to be aware of user (DoD) needs and provide 
more functionality in M&S tools. The functionalities were 
directly related to Verification, Validation, and 
Accreditation (W&A) along with the Defense Standardization 
Program (DSP). 

The M&S Coordination Office (MSCO) promulgated in 2000, 
operating procedures for simulation developers on standard 
methodologies, programming practices, and data processing 
with no mention of simulation reguirements or potential 
capabilities. These requirements were not stated and left 
for developers to interpret end user and stakeholder needs. 
Defining capabilities required to model a SBE may hopefully 
aid in the development of M&S tools specifically for SBE, 
with emphasis on modeling T-craft. The W&A process was put 
in place to govern simulation products and ensure that there 
was quality control that matched user's needs with results. 
The W&A process seems to have led to specific tools for 
specific needs, which has limited the use of M&S tools in 
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the DoD. Providing a list of general capabilities that are 
reguired by the DoD to be present in M&S tools may increase 
their uses in decision making. 

B. LINKS TO M&S DOMAINS 

The purpose of M&S in DoD has always been to accomplish 
requirements with less money, time, and loss of life. M&S 
offers decision makers, developers, and warfighters the 
ability to experiment with ideas without the risk associated 
with real-world experimentation. Users of M&S are important 
to the development of tools that are used in the DoD 
communities. Given that there are defined community domains 
for M&S within DoD, the link between those domains and a 
capability hierarchy should be self-evident. The 
characteristics of M&S domains lead themselves to be 
interpreted in a way to suggest that M&S tools need to be 
usable, flexible, and scalable as introduced in Chapter I. 
Four of the seven DoD Communities are steeped in M&S 
application of developing technology and material solutions— 
Acquisition, Analysis, Planning, and Test & Evaluation. The 
remaining three. Training, Experimentation, and Intelligence 
tend to be directed at operational considerations post 
production phases. Acquisition is the overarching domain, 
where Analysis, Planning, and Test & Evaluation begin to 
narrow the scope of M&S applications. These domains provide 
data and understanding of systems for further development. 
The derivations of M&S requirements from these communities 
provide an essential framework for defining a capability 
hierarchy. A description of each of these communities 
follows, along with the ways in which a capability hierarchy 
would be useful for that domain. 
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A New Approach for Managing 
DoD Modeling and Simulation (M&S) 


New M&S Management Structure Organized by Communities. 


Designed to Support & Integrate M&S Activities across the Department. 

Led by a 1 to 2 Star M&S Steering Committee (M&S SC) to provide governance. 



Components 


OSD, Joint Staff, CQCOMs, Services 


Common and Cross-Cutting M&S Tools 


Common and Cross-Cutting M&S Data 


Common and Cross-Cutting M&S Services 


Acquisition 


Analysis 


Planning 


Testing 


Training 

AT&L 


PA&E 


JS 


DOT&E 


P&R 



&JS 


& Policy 


&AT&L 




Experimentation 

JFCOM 


Goal : Establish corporate M&S management to address DoD goals: 
Leads/guides/shepherds the $Bs in DoD M&S investments; adds value 
thru metrics & ROI-driven priorities; and seeks to provide transparency. 


Figure 2. M&S Domain Management Diagram (From MSCO, 

2007). 


1. Acquisition 

The first community acquisition is at the heart of 
major developmental concepts that govern the progress of the 
concept's evaluation from birth to death, which is referred 
to as the life cycle. M&S is rooted in initial phases of 
system life cycles because of the potential reduction in 
time, risk, and cost it offers. As noted in the Office of 
Secretary of Defense report (1997), The Study on the 
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Effectiveness of M&S in the Weapons System Acquisition 
Process, M&S can be used to integrate acquisition functions 
like design, manufacturing, and requirements together. M&S 
tools can contribute to the development of actual prototypes 
of T-craft by modeling capabilities and testing them in 
extreme conditions. The complexity of the SBE concept lends 
itself to use of M&S to integrate physical research with 
operational tactics and joint effectiveness. Defining the 
M&S capabilities based on the process can assists in system 
acquisition of SBE by affecting multiple aspects of the time 
delay in reaching for the warfighters. 

2. Analysis 

The Program Analysis and Evaluation (PA&E) department 
within the Office of the Secretary of Defense (OSD) is 
tasked with breaking acquisition projects in smaller 
understandable parts. This basic concept is the core of DoD 
acquisition analysis and how it was applied in this 
research. The analysis of SBE effectiveness in situations 
provides insight to decision making on the future of systems 
and in how to further develop the programs. This goal is 
accomplished by collecting data on cargo transfer rates and 
amounts, transit times in a given environment, and 
survivability rates with varying defensives. M&S tools used 
for analysis should be able to provide basic information on 
systems by performing statistical analysis on simulations 
iterations. They are also associated with exploration of 
the solution space SBE occupies. This method uses the 
trends that models display in M&S environments to develop a 
common performance measurement. Operators are involved at 
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all levels of the analysis process; therefore, usability in 
the capability hierarchy is important in M&S. 

3. Planning 

Planning has many different roles in system 
development. The first role is production factors like 
manufacturing schedules that affect the delivery of systems. 
The second role is logistical needs for operating forces. 
Lastly, operational planning plays a major role in 
determining the reguirements for systems uses. The 

requirements are wrapped within the capability of M&S tools 
to model and simulate planning elements that affect SBE 
deployment. M&S can integrate production elements into the 
planning process. A driving factor is measuring flexibility 
in M&S tools used for planning SBE craft capabilities and in 
its use within military applications. Thus, flexibility is 
a capability crucial to planning. 

4. Test & Evaluation 

The office of the Director of Operational Test and 
Evaluation (DOT&E) is responsible for prescribing policy of 
Testing and Evaluation (T&E) in the DoD. T&E is used to 
measure prototype status and determine when systems are 
ready for full rate production. T&E is important in system 
development in determining capabilities achievement. M&S 
can greatly assists in this process by simulating models of 
systems in virtual environment. M&S may not complete 
validate their effectiveness, but can make considerable 
steps towards evaluating measures of effectiveness. M&S 
should be used throughout the development of SBE, as well 
with T&E craft performance. 
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Dividing industry from DoD is the fact that commercial 
M&S is not regulated. Industry's use of M&S can be 
dramatically different than DoD at times, even more of a 
reason to standardize the capabilities of M&S for use with 
military concepts. M&S, on the other hand, must be flexible 
enough to handle extreme situations that are required in a 
testing environment and that are where the hierarchy is 
limited in its application. Standards are not all 

encompassing and some amount of non-standards can be 
beneficial. 

C. ACQUISITION FRAMEWORK 

The three capabilities derived in this study overlap 
multiple M&S domains. Usability is essential to Analysis 
but is less critical in planning and testing. Conversely, 
flexibility is important in planning but less in Analysis. 
Scalability is no different and is grouped into the 
acquisition system, but it is more involved in planning and 
analysis by focusing on large number high fidelity unit 
operations. Figure 3 illustrates the relationship between 
M&S domains and the upper levels of the capability 
hierarchy. 
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Figure 3. Capabilities Hierarchy Links to M&S Domains. 
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III. POSSIBLE SOLUTIONS 


This chapter discusses the constructive-based M&S tools 
that are contained in the SBE M&S possible solutions. The 
solution space for modeling a SBE, encompasses a wide 
variety of M&S tools and presents a challenge to selection. 
Listings of M&S tools that have the capability of modeling a 
SBE Scenario are identified to help focus research efforts. 
There were three time-step based models and three next-event 
based models selected for evaluation of capabilities. This 
chapter was designed to identify and briefly introduce the 
selected M&S tools used for modeling an SBE Scenario. Table 
3 displays the six M&S tools selected and its corresponding 
information. 


M&S Tool 

Version 

Joint Conflict and Tactical 

Simulation (JCATS) 

Version 8 

Map Aware Non Uniform Automata 

(MANA) 

Version 4.04.1 

Pythagoras 

Version 2.1.0 

Naval Simulation System (NSS) 

Version 3.4.1 (Beta) 

Simkit API 

Version 1.3.8 

Arena Simulation Software 

Version 12.0 


Table 3. M&S Selection Information. 
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A. 


M&S CATEGORIES 


There are two classical ways to study a system: 
experiment with the actual system or with a model of the 
system. This study utilized the latter approach on the SBE 
concept to determine a basic capability hierarchy. All 
models are a part of the live, virtual, or constructive 
taxonomy. This taxonomy has varying levels of human 
interface with different types of simulations. The first 
category is a live simulation that has actual operators 
interacting with real systems in a real environment. The 
second category is virtual simulation, which differs from a 
live simulation by the fact the systems are simulated and 
there is a human-in-the-loop. The third type, constructive 
simulation, is a man-made model that executes with simulated 
operators and simulated systems (DoD, 1998). This research 
focused on the use of constructive models in the DoD and 
industry. 

1. Constructive Models 

DoD defines a constructive based model as one in which 
users operate and provide inputs to the simulation scenario 
where the adjudication is determined strictly by the 
algorithms coded into the program (DoD, 1998) . All 
simulations used for comparison were within the constructive 
simulation trade space. In this thesis, six different 
simulations were chosen to give a clear representation of 
two separate types of simulation, time-step and next-event 
based models. These two types shared autonomous and non- 
autonomous agent entities qualities. Figure 4 depicts the 
relationship between the two types. 



Constructive 


Time Step 


Next Event 


Agent 


Figure 4. M&S Space for SBE Modeling, 


According to Law and Kelton (2000), there are three 
dimensions to classify M&S tools. The first dimension is a 
dynamic model that changes over time to allow for 
interaction of the simulation in a SeaBase environment. The 
second is a stochastic model that provides random inputs to 
produce a realistic capability. The last is the capability 
of the simulation to take discrete time-steps for analysis 
of a single event to observe interactions of the model. 

There is no one single program to simulate the SBE 
concept that incorporates the three dimensions. When used 
together, the three types of simulation are a possible 
solution that can provide information on one or all Measures 
of Performance (MOP) of the SBE Scenario that the U.S. Navy 
has defined as apart of the Sea Power 21 concept. The 
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hierarchy of capabilities was used to determine the level at 
which a tool could be suitable to model and simulate a SBE. 

2. Autonomous Agent Based Models 

An Autonomous Agent-Based Modeling (AABM) was defined 
in this study as a program that makes use of personal 
attributes to govern the actions of simulated models. 
Programs are created to have individual entities act in a 
common way to make autonomous decisions based on a set of 
organized rules. According to Bonabeau (2002), there are 
three benefits to AABM that may prove to be an important 
factor when under evaluation for SBE modeling. The first 
was the ability of AABM to interact with the environment as 
the scenario unfolds and make decisions not based on 
probabilities. This benefit will make the AABM highly 
usable in SBE scenarios. The next was the flexibility of 
the agents to behave like live operators and be easily 
modeled into the scenario. The third was the resolution 
control of AABM being able to adjust force levels, making 
them scalable. 

There are several AABM programs that are available 
commercially or open source that can be useful to decision 
makers. The two AABMs used in this study were New Zealand's 
Defense Technology Agency (DTA) Map Aware Non-Uniform 
Automata (MANA) , and dual development by the U.S. Marine 
Corps and Northrop Grumman on Pythagoras Simulator, an 
agent-based model. The development of AABM has produced 
tools that can provide analysts the capability of 
experimenting with scenarios. Agent attributes are 
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integrated into the various simulations and used to create 
agent actions that are indicative of real motion by real 
players. 

B. TIME-STEP BASED MODELS 

Time-Step Based Models (TSBM), or continuous-based 
models, are designed to handle the propagation of predicted 
agent action changes over infinite time increments. 
Continuous-based simulations are represented by the changing 
of state variable with respect to time (Gordon, 1978). TSBM 
used in problem-solving situations with high resolution 
scenarios should provided strong analysis tools. TSBM have 
also been useful in enabling the modeling of dynamic 
phenomena that autonomous agent-based simulations typically 
model. The complexity of the simulation''s functionalities 
introduces many issues that are directly related to 
simulation capabilities. For example, the larger number of 
entities in a model may cause the computational times to 
increase. 

The three TSBM were Lawrence Livermore National 
Laboratory's Joint Conflict and Tactical Simulation (JCATS), 
MANA, and Pythagoras. Each is posed for the T-craft 
scenario and provided insight into the survivability of 
units in a hostile environment. JCATS was created with 
detailed physics model for engagement and motion through 
water, where MANA and Pythagoras have evenly distributed 
terrain effects on entities motion. These models are highly 
scripted, which give them a high degree of usability but 
limited stochastic application. Their rigid and complex 
development gives them validation in real-world 
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applications, such as training and mission rehearsals; 
however, scenario generation was dependent on a high level 
of proficiency. 

1. JCATS 

The JCATS simulation results were used from a previous 
study conducted by Lieutenant Richard Jimenez, U.S. Navy. 
His results are described within the unpublished article 
"Assessing the Requirements for the transformable Craft: A 
Framework for Analyzing Game Changing Capabilities." 
Jimenez's (2010) study that was in conjunction with the 
Systems Engineering studies of T-craft research at NPS. 
This work was designed to support a direct evaluation of 
JCATS simulation capabilities of an SBE using the Advanced 
Scenario as the basic framework. Jimenez was also able to 
establish a concept of operations scenario for data farming 
and conducting large-scale, multi-variable analysis on SBE 
capabilities. 

JCATS is a deterministic computer-based model that 
offered a high level of accuracy to SBE Scenarios. Its high 
fidelity of entity capabilities, which incorporates actual 
physical restraints, enabled simulations results to emulate 
real-world characteristics. Military applications have been 
for training, analysis, and mission planning. JCATS 
usability comes from its ability to simulate urban terrain 
to support both asymmetrical along with conventional threat 
environments, along with allowing users to manipulate 
entities. JCATS has a wide range of functionalities with 
models of individual soldiers, vehicles, and weapons systems 
(USJFCOM, 2010) . JCATS was designed to be a virtual 


28 



simulation with human-in-the-loop decisions being made. 
However, a constructive approach was taken. 

2. MANA 

MANA is a stochastic AABM that attempts to bridge the 
gap in deficiencies in highly detailed models such as Janus 
Simulator from Training and Doctrine Command White Sand 
Missile Range, Close Action Environment model from the 
Defense Science and Technology Officer (DSTO), and JCATS. 
The use of AABM is centered on analysis of individual unit 
actions in a bottom-up approach to warfare. MANA was 
developed from two basic concepts: behavior and priority 
settings. This simulation design expanded from the Marine 
Corps Combat Development Commands' Project Albert and the 
Enhanced Irreducible Semi-Autonomous Adaptive Combat (ISAAC) 
Neural Simulation Tool (EINSTien). The use of the model was 
derived from the use of entity attributes that govern 
actions and decision making. The non-linear nature of model 
outcomes was important in obtaining a stochastic result 
(Lauren & Stephen, 2002). 

3. Pythagoras 

Similar to MANA, Pythagoras is a next generation 
Project Albert concept that is open-sourced from the U.S. 
Marine Corps. Pythagoras is the introduction of AABM into 
simulation by Northrop Grumman to use Fuzzy Logic in a 
Graphical User Interface (GUI) program. The basic idea 
behind Pythagoras was to enable analyzers to create 
behaviors and not the software. It has the capability to 
use probability tables, but more importantly is 
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stochastically based on single entity decision making 
(Bitinas, Henscheid, & Troung, 2003). 

Time-step based models can provide a wide range of 
interactions for the SBE Scenario analysis. Models like 
MANA and Pythagoras incorporate autonomous agent-based 
models and inject stochastic processes into a scripted 
model. JCATS supports entity based physics of individual T- 
craft units allowing for the environmental factors to be 
integrated into the SBE Scenarios. MANA and Pythagoras 
provide attribute based interfaces that enable users to 
influence entities actions and provide randomness to the SBE 
Scenarios. 

C. NEXT-EVENT BASED MODELS 

A next-event or Discrete Event Simulations (DES) are 
applied to many computational problems that occur over a 
finite amount of time (Gordon, 1978). The typical models 
are single server and queuing event scenarios. The M&S 
tools evaluated were NPS Simkit DES, Rockwell Automation 
Arena software simulation, and Lockheed Martin'' s Naval 
Simulation System (NSS), located at NPS. The T-craft 
scenario was applied to the three simulation programs and 
evaluated for desired functionality for modeling and 
simulating. DES's wide range of applications made it 
suitable for measuring performance parameters. DES provided 
analysis data on processes involving T-craft and its ability 
for cargo and equipment transfer to and from the SeaBase 
Operations. 
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1 . 


Naval Simulation System 


NSS is an object-oriented Monte Carlo simulation 
developed by Space and Naval Warfare Systems Command 
(SPAWAR) . It is a DoD M&S tool for multi-warfare mission 
area analysis. Previous uses have been operational 
planning, systems effectiveness, and fleet exercises. Its 
ability to receive information makes it useful for analyzing 
ongoing operations course of actions. NSS provides measures 
of effectiveness and performance for predetermined 
categories that enable analysis of virtual systems (Metron 
Inc, 2007). 

2. Simkit 

Simkit is a simulation package used for creating DES 
models with a Java based computer program language. Time- 
steps within Simkit are event driven rather than timed 
incremented. Simkit can be utilized for movement and 
sensing events in a military scenario and is based on event 
graph logic. Entities were represented in an abstract way 
as to emulate the real characteristic of systems. Simkit is 
a component-based modeling tool that used an Application 
Programmer Interface (API). This is fundamentally different 
that GUI models (Buss, 2002). 

3. Arena 

Arena is a Monte Carlo DES similar to Simkit but 
provides a GUI vice an API. This difference in simulation 
design allowed for animation of the model and user interface 
vice direct interface with program code. The usability of 
Arena is what enables decision makers to easily obtain 
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results through their current operating system. According 
to the Rockwell Animation Company, the use of Arena 
simulations in the health care industry has shown benefits 
in patient, staff, and facility studies to improve admission 
processes and planning (RA, 2007). 

Next-event based models enhanced processing of the SBE 
Scenario events to allow for precise adjudication of 
interactions. NSS was similar to JCATS, in that the physic 
modeling of the entities provides environmental restraints, 
but added to the processing power of the SBE Scenario by 
precisely accounting for interaction or engagement. M&S 
tools like Simkit and Arena provided another benefit to a 
SBE Scenario, which was modeling the interactions vice the 
entities. The flow chart analysis enabled the user to 
analyze the SBE Scenario to affect changes and improvement 
the efficiency. Simkit added another adjudication dimension 
by being able to adjudicate limited interaction (user 
defined), where Arena was strictly flow chart assessment. 
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IV. CAPABILITIES HIERARCHY 


A. DEFINING SEABASE ENABLER CAPABILITIES 

The overarching goal, as described in Chapter I, was to 
define the needs of a SBE in future operations and translate 
them into capabilities for a simulation or a "suite of 
simulations" that can be applied broadly across the M&S 
solution space. The capability hierarchy is defined as the 
body of functionalities that a simulation may possess to 
model SBE Scenarios. An example of functionality is the 
control panels used in the windows operating system for 
Personal Computers where settings of the display (screen) 
can be directly adjusted with instant feedback to the user. 
User feedback is at the heart of M&S and why it is extremely 
useful for analysis. Modeling a system seems to require 
unique setting properties that enable the translation from 
real world to a synthetic environment. These properties 
that allow for modeling are what will be described as 
capabilities for a simulation. The generation of 
capabilities discussed in Chapter II link to the application 
of these capabilities within the seven M&S domains (DoD, 
2000 ) . 

M&S attempts to offer insights into performance of 
technology in artificial environments. The development of 
advanced technology has started to rely heavily on M&S for 
testing of concepts. M&S partially allows for a translation 
of simulation results to performance parameters that 
advanced systems may possess in real settings. The specific 
needs of SBE present a challenge to developers, requiring 
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assumptions to be made on future environments and 
capabilities. Decision makers are, in turn, forced to 
consider key system parameters and performance levels 
without the benefit of having a proven system to base 
judgment on. Simulations available to those groups are also 
available to academia, including research work conducted by 
NPS. Simulations chosen for this comparison of capabilities 
were based on M&S tools available at NPS. 

The T-craft is an ideal candidate for M&S analysis. 
The modeling of T-craft as an SBE involves the development 
of scenarios to help identify potential requirements of a 
simulation. The dynamics of the SBE situation allowed for 
the extraction of simulation functionalities that were 
essential for actually modeling an SBE. What drives that 
need for modeling a SBE? The T-craft projected capabilities 
are not typical of a traditional amphibious craft. SBEs are 
being designed to fill the gaps of current landing craft 
that are limited in cargo capacity. The overarching goal of 
using M&S tools for analysis of T-craft is to show options 
in SBO. 

B. MEASURES OF EFFECTIVENESS 

The objective of modeling a SBE, such as T-craft, was 
to represent Basic and Advanced Scenarios, allowing for the 
assessment of T-craft's responses and simulation 
capabilities. Given that SBE concepts are being developed 
for cargo transfer, the Measures of Effectiveness (MOE) 
could then be directly linked with the outcomes of the four 
situations mentioned in the previous chapters. MOEs were 
only briefly introduced to relate the importance of cargo 

transfer in SBE situations to the simulation capabilities. 
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A possible MOE that was considered with humanitarian 
relief efforts is the approval of public opinion towards 
relief efforts that are received by host nations. Measures 
used for performance were the delivery of cargo and 
equipment to forces in combat operations. In other words, 
100 percent of cargo and equipment delivery should 
effectively increase public opinion or sustain combat 
operations by use of SBE large capacity capabilities. Thus, 
T-craft's cargo capacities offer potential support to a wide 
range of military operations. 

C. MEASURES OF PERFORMANCE 

The Measures of Performance (MOP) that were used for 
the Basic and Advanced Scenarios were general and may not be 
available in all M&S tools. These MOPs were introduced to 
evaluate whether an analysis capability was available within 
a simulation program. The main MOP was defined as the 
amount of cargo transferred to the line of embarkation. In 
this research, the line of embarkation was defined as the 
shore landing site along the coastline. Cargo transfer was 
defined as the transfer of any resource carried by T-craft 
to an entity in the model that represented a shore landing 
site similar to the crisis relief area of operations. The 
secondary MOP was transit times associated with movement of 
the SBE to shore landing sites from debarkation points. The 
third MOP was the survivability of T-craft in a hostile 
environment with varying hostile and escort forces. 
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1 . 


Cargo Transfer 


It was important to distinguish the differences between 
cargo and equipment that could be carried by naval craft. 
In this research, cargo referred to supplies other than 
large machinery that could be used for amphibious assaults. 
T-craft is projected to have a cargo-carrying capacity that 
is unprecedented by previous landing craft used for cargo 
transport. According to Jane's Fighting Ships, current 
capabilities in cargo transfer craft are nominally at 60 ton 
payload. The capability of T-craft storage capacity is 
projected to be approximately 10 times that of those craft 
in use today. Cargo capabilities are difficult to represent 
in real-world systems and in simulations where modeling the 
dynamics of transferring quantities is not standardized. 

Representing cargo in M&S tools was limited, and use of 
unrelated simulation objects were used to act similar to a 
type of resource. In the two types of simulations, time- 
step and next-event, there were different methods of 
modeling cargo and transfers of quantities from one entity 
to another. Given the diversity of the simulations, there 
was no standard way to represent cargo or a transfer of that 
cargo. Common elements present across simulations were fuel 
elements that were used in time-step simulations. 

2. Transit Times 

Logistics support is highly dependent upon what time 
the supplies arrive to the front lines. Sequencing 
operations are often limited to logistic capabilities. An 
important aspect of modeling a SBE was the time required for 
a T-craft to transit from debarkation point to the SBO and 
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then to the shore. Transit times are helpful in determining 
needed speeds of a T-craft in different modes. These needs 
are derived from mission requirements and end users needs. 
Transit times were used to confirm the presents of a 
capability within a simulation, and its ability to measure 
time distance problems that could be integral to decision 
making and planning. 

3. Survivability Rates 

The third MOP, survivability of a SBE, was the constant 
element in simulation development. T-craft prototypes are 
being developed with limited self defense and will require 
protection in a hostile environment. The Advanced Scenario 
introduced a hostile environment through which the T-craft 
transited. Survivability was defined as T-craft being able 
to transfer cargo to the shore landing site, while 
maintaining a capable speed of 40+ knots through the hostile 
environment. The use of this MOP on simulation capabilities 
was that damage sustained by T-craft in iterations should 
have an effect on performance. 

D. M&S IMPACT ON SEABASE ENABLER SITUATIONS 

The introduction of a potential revolutionary platform 
like T-craft may have dramatic effects on current force 
structures and deployment considerations. Stakeholders like 
the Navy, Marine Corps, Army and other key military entities 
have collaborated with ONR to develop the SBE capabilities 
required for operations in SBO (Flitter & Sintic, 2009) . 
These capabilities were published in the BAA 05-020 by the 


37 



ONR. In general, M&S is well suited to model INPs like T- 
craft and give decision makers key insights to its potential 
as a SBE. 

Although the two types of simulations contributed to 
the goal of analyzing a SBE in the situations like Peace 
Keeping and Major Theater War, their advantages vary. AABM, 
which is commonly found in time-step based models, provided 
a dynamic environment to model interaction with other forces 
in a given scenario. This allowed for adjudication of 
engagements with force-on-force. Time-step based modeling 
also enabled replications and the integration of complex 
algorithms to perform data analyses. A DES modeled specific 
processes within a scenario to isolate factors and measure 
parameters that may be critical for decision makers. 

The disadvantages were centered on the purpose and use 
of each type of simulation. Defining capabilities of a 
simulation for a SBE required analysis of a wide range of 
simulation functionalities that were partially incorporated 
into these two types of M&S tools. DES were not as 
versatile as agent-based models. DES are queuing models 
that have stochastic inputs with distributed results. 
Agent-based models were usable and scalable but rigid in 
applications of performance measures. Most simulations did 
not allow access to programming code, which was critical to 
modeling a SBE for accurate representation in simulation 
environments. AABM was highly usable and offered the fewest 
disadvantages. AABM had complex requirements for measuring 
performances and obtaining tangible results. 

The downside to M&S was that a single simulation could 
not be used to answer every question of the SBE Scenario. 
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Investigating the four MOP required multiple points of view 
into the SBE concept. These types of simulation offered 
different perspectives on all MOPs that were analyzed in T- 
craft scenarios. For example, an AABM determined the 
effective number of escort ships needed in an Advanced 
Scenario for the safe transit of the SBE with limited 
defenses. AABM could not be used to assess the cargo load 
capacity and transfer rates that a DES could model with more 
accuracy, with regards to waiting queues processes. DES was 
also well suited for measuring multiple iterations in tandem 
or in series. Nevertheless, the survivability of T-craft 
with escort ships may have been best analyzed in a time-step 
simulation with look up tables for real-world probability 
engagements. 

Basic surface engagements and cargo transfers were used 
for modeling T-craft projected capabilities. The Basic and 
Advanced Scenarios described in Chapter V were used for the 
purpose of defining a set of capabilities that all models 
possessed. The following sections delineate the capability 
hierarchy used for analysis of the six M&S tools. 

E. CAPABILITY HIERARCHY 

M&S tools have inherent functionalities that can be 
used in all areas of DoD and industry for analysis, testing, 
training, and planning. These functionalities were the 
backbone of the capability hierarchy. Figure 5 illustrates 
the tiers of the capability hierarchy. The four levels of 
the capability hierarchy are: Capability of a simulation. 
Characteristics of a Capability, Abilities of a 
characteristic, which were referred to as "ilities," and 
Traits of 


"ilities. 


The Trait tier represented 
3 9 



functionality groupings that were used to evaluate M&S 
tools. This section delineates the hierarchical structure 
and body used for analysis of the six M&S tools used in this 
study. The levels of description directly reference M&S 
domain ideology and use of common applications in DoD to 
support the preferred capabilities of an M&S tool. 

The capabilities in the hierarchy were derived from M&S 
Domains in DoD, and are Usable, Flexible, and Scalable (DoD, 
1995) . Each simulation was evaluated based on how well it 
fit into the hierarchy of capabilities using the Basic and 
Advanced Scenarios. 



Figure 5. 


Capability Hierarchy Structure. 


1. Evaluation 

The evaluation of M&S tools were based on a Boolean 
value in an attempt to removed subjectivism from the base of 
the hierarchy. The functionalities were observed and 
recorded as being present or not. This enabled the 
application of values to be applied to functionalities. 
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Value of one was assigned to an observe functionality, where 
the total number of observed functionalities were used as 
proportions. The use of probability properties were used 
for evaluation. This research kept the values the same for 
all functionalities but recognize that a weighted scale be 
applied to future evaluations where elements of the 
hierarchy could be more important than others. 

2. Roll-Up method 

The functionalities within the capability hierarchy 
were used as the baseline total proportionality for 
evaluation. This section explains the method used to roll 
up the total probability of the individual capability. A 
single functionality was set equal to a value of one. The 
total number of functionalities within a given capability 
was then used to determine the contribution of each one, 
where the variable (f) represents functionality. The 
summation of each capability was then combined up the 
hierarchy to the characteristic level and follows the 
Probability Assignment Rule (De Veaux, Velleman, & Bock, 
2009, p. 371). 

n 

^ - ^I + ■*v+l + f;+2 + + + fn Equation (1) 

i - 1 

A roll-up method was then used to calculate the 
contribution of hierarchy elements in the capabilities. 
Using Equation (1), the total contribution of 
functionalities of a trait were summed and rolled up into 
the hierarchy to determine the capability of an M&S tool. 
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This was done by normalizing the capabilities vector. The 
variable (c) represents the three capabilities defined in 
the hierarchy. 


C = 


c L = Usability 
c 2 = Flexibility 
c 3 = Scalability 


Equation (2) 


The roll-up method was used to compare the three 
capabilities of an M&S tool. The asymmetrical design of the 
capabilities hierarchy was not conducive for a one on one 
comparison of single elements. The number of 
functionalities in each capability was not standardized 
across the hierarchy, therefore, a standardization method 
needed to be used. Normalizing the probability values were 
calculated similar to normalization of vectors where the 
varying number of functionalities are accounted for. Once 
the capabilities were standardized, the average was then 
calculated to compare the capabilities of all the M&S tools 
to determine the best solution for a simulation or "suite of 
simulations ." 

F. USABILITY 

The definition of usability as defined in American 
Heritage is the capability of any given object to be used. 
The ability of a simulation to be used by users certainly 
was a capability that was required when applying it to 
analysis. The meaning of usability was also open to 
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interpretation of the users. There are many aspects of M&S 
that could be measured and observed to determine if a 
simulation is (1) available and (2) usable by decision 
makers (who are not computer programmers). Figure 6 shows 
the hierarchical structure for Usability. 



Figure 6. Usability Hierarchy Branches. 


The end user's level of knowledge of simulations was 
ultimately dominated in how usable it was, but there are 
other factors that allow for a simulation to be useful in 
DoD. One important aspect of a simulation must be that it 
has been W&A. This concept of W&A was considered as a key 
characteristic to usable simulation due to its rigorous 
testing and application of a simulation's capabilities (DoD, 
2003) . 

The second characteristic, user interface, applied to 
features that the user accesses for manipulation of settings 
in the M&S tool and those functionalities to create models. 
DoD applications of M&S tools often require explicit 
interface methods to handle a wide range of settings for 
modeling scenarios. 
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1 . 


Validation 


The validation of M&S tools was important because of 
the continued support of major DoD decision making 
organizations and processes. Validation was defined as the 
process of determining the degree to which the simulation 
could accurately represent the real world (DoD, 1998) . This 
was a key element with regards to usability of a simulation. 
The W&A process was not directly used for determining the 
simulation capabilities, but had a role in defining those 
end user needs (DoD, 2003) . 

a. Construct Abilities 

Given that a simulation was validated for use, the 
first step in assessing its usability was to assess its 
ability to handle complex SBE Scenarios. This included the 
ability to simulate multiple entities in an environment that 
presented interactions among multiple entities. An entity 
was a single player or agent in a simulation that was 
defined by the user of the M&S tool (Bonabeau, 2002) . 
Figure 7 shows the hierarchical structure for "construct 
abilities." 
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Dynamic Situations 


Replications 


_ ± _ 

Sensor Probability Tables 
Weapon Probability Tables 
Individual Unit Actions 
Agent Information 
Communication 
Waiting Queues 
Personal Settings 
Semi-Automated Forces 



Simulation of a User 
Defined Model 
Multiple runs Defined by 
User 

Measures of Performance 

Parameters 

Reset Simulation 

Parameters 

User Defined Output 

Start/Stop Criteria 

Accuracy 

Spot Sampling _ — 


Figure 7 . 


"Construct Abilities" Hierarchy Branches. 


(1) Dynamic Situation. The first situation 
to consider was the dynamics of possible scenarios with 
multiple entities that acted as individuals interacting in a 
simulation environment. In this thesis, a dynamic situation 
was defined as a non-deterministic model where entities 
acted independently from one another and whose actions were 
not predetermined. AABM are an example in which the 
simulations could create a dynamic situation with multiple 
personal attribute settings. Other aspects of dynamic 
situations were associated with the individual entities and 
their place within the simulation environment. There are 
several functionalities that were present in a dynamic 
situation that begin with probabilities to facilitate a non- 
deterministic model. Other functionalities included 
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individual entities properties and interactions of those 
individual entities with each other, which did or did not 
include probabilities. 

The idea of using probabilities is not new to 
military operations and planning. Classic war gaming 
methods have used probability tables to simulate the 
partially random results of interactions of units on the 
battlefield. One way to make a model non-deterministic is 
to use sensor and weapon probability tables. The level at 
which they were implemented was based on the resolution 
needed, but in this thesis basic use of probabilities was 
sufficient to display the functionality in the simulation. 

Inherent in dynamic situations is the 
individual entities characteristics that are displayed. 
AABM represented this functionality with a high degree of 
effectiveness. The level of resolution at the individual 
entity provided the maximum amount of dynamics in the 
simulation. The first functionality was that the individual 
unit actions were different from all other elements within 
single simulation iterations. It then followed that if high 
resolution was present, individual entities also needed to 
possess basic viewable characteristics like entity course, 
speed, positional data, refueling rates, and cargo 
capacities levels. 

An important functionality in dynamic 
situation was the access to individual entity controls. 
AABM are rooted in the concept of controllable attributes 
for agents within the simulation. These personal settings 
included but were not limited to preferences to other 
entities, task oriented actions, and objective completion. 
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A simulation that enabled the user to adjust personal 
settings of an entity possessed this functionality. 

The use of Semi-Automated Forces (SAF) has 
become obsolete in the development of AABM. The reason for 
listing these types of forces was to include a wide range of 
aspects in the hierarchy to be able to apply it over 
simulations in M&S. SAF were the first attempt to represent 
human behavior in a constructive simulation. There may be 
some level of automation to entities in M&S that is not 
associated with AABM. SAF covered all other force 
automations that were encountered through this research 
(DoD, 1995). 

Communications added complexity to dynamic 
situations by allowing information of scenario events to be 
distributed to multiple entities. The use of communications 
by entities provided a situational awareness influencing 
actions. Operations that relied on communications were 
defined as: Command and Control, Military operations other 
than Warfare, and Logistical. 

Waiting Queues are typically characterized in 
logistical operations where transfers occur and are time 
dependent. A DES is designed to specifically create waiting 
queues to measure transfer rates and amounts. This property 
was the basis for introducing waiting queue functionality in 
the hierarchy. A simulation with the capability to delaying 
transfers based on facilitation restriction of entities 
capabilities was defined to have waiting queue 
functionality. 
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Replicable. 


(2) Replicable. The ability to run a 
simulation over multiple iterations is to allow for varying 
results in a dynamic situation. The main reason for 
simulations to be replicable was to provide statistical 
data. The M&S tools provided a range of possible answers 
for users. The data collected from the replication provided 
insights to model performance. This information would 
otherwise not be obtained without the expensive generation 
of actual prototypes in the physical development of the 
system. 


M&S tools should have certain control 
functionalities associated with the replication of models. 
The users should have the ability to define and use a model 
in the simulation. This classically is seen in time-step 
simulations where entity models are available for use in the 
simulation without access to action settings. This has been 
recently addressed in AABM where the default settings are 
not sufficient for simulation and attention must be paid to 
the design of the simulation. The second functionality was 
the ability for the user to define a predetermined number of 
replications for a simulation. When dealing with complex 
models, time played a considerable factor in computational 
run time. 


Along with replication, control is the 
ability to select specific MOP. A user should be able to 
select pertinent MOP for the simulation. This functionality 
also assisted in reducing time in other ways. Simulation 
output often was not designed effectively to allow users to 
rapidly depict analysis information at any point in the 
iteration. A spot sampling of information in the run should 
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be functionality to allow the user to select key MOP for 
output files increased the analysis capability. MOP 
included system parameters associated with times or user 
defined variables. 

A simple functionality was for users to have 
the ability to reset simulation parameters during the 
simulation. This included the need to start and stop the 
simulation base on certain criteria. User needs vary with 
situational requirements and M&S tools must be versatile in 
handling both depth and breadth of requirements. 

The last functionality of replication that 
was used in this research was accuracy. Accuracy was 
defined as the ability of a simulation to produce a result, 
and/or contained in a confidence interval common to 
statistical analysis. Optimization methods often had 
difficulty in determining solutions to complex situations 
with multiple variables. This often left simulations 
without ends. It was foreseeable that optimization 
approaches will be employed in M&S analysis of DoD systems, 
therefore accuracy was included in the capabilities 
hierarchy. 


b. Supportabilities 

The second step in assessing M&S tools usability 
was the level of supportability that simulations had in the 
form of user execution. W&A required simulations to have 
minimum levels of information (support and documentation) 
associated with M&S tools to be approved for DoD use (DoD, 
2003). These support issues may be key to use of 
simulations in DoD at the higher levels of the decision 
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making process. W&A requirements for accreditation were 
the basis for support "-ilities" of a simulation in the 
hierarchy. The information listed in the W&A instruction 
is the standard for M&S tools used and are common in high 
profile models. The two categories of supportabilities are 
contractor support and user documentation. Figure 8 shows 
the hierarchical structure for Supportabilities. 



Supportab¬ 

ilities 



Contractor Support 


Documentation 


Basic Information 


Functionality Tutorials 

Reach Back Availability 


Help Windows 

Points f Contact 


User Manual 

Training and Education 


Publications 

Feedback Loop 


Online Support 

Authoritative Sources 


- 

- 

1----- 


Figure 8 . 


Supportabilities Hierarchy Branches. 


(1) Contractor Support. There are basic 
elements of simulation information that should be contained 
in the associated files of a program that the contractor or 
programmers provide. A comparison between the defined 
capabilities hierarchy and the W&A process are listed in 
Table 4. This comparison was used to show the validity of 
informational items that were used in the capability 
hierarchy, which indicated what additional items were used 


50 




in evaluations with All items listed in the supportabilities 
category are delineated in the capabilities hierarchy. 

Supportabilities Comparison 

Verification Support ilities 

Verification Agents 

Version/Release Simulation Version Number/Release 

information 

Identify Developing Organization Listing authority sources used to 

produce simulation code 

Methodologies 
Verification Results 

Validation Support ilities 

Validation Agents 
Federation Version 

Identify Developing Organization Listing authority sources used to 

produce simulation code 

Simulation Conceptual Model 
Methodologies 
Validation Data 
Validation Results 
Limitations 

Sponsors information Listing of Points of Contacts held 

with the M&S tool 

Model Intended Use 
Requirement Gaps 


Assumptions 




Scenarios 


Representation of concepts. 
Processes 

Environmental, Missions, 
Organization, & Systems 
Representations 

Doctrine Tactics, Behaviors, and 
Performance Algorithms 

Capabilities and Limitations 
Evaluation 


W&A Documentation 


Support ilities 

Last Upgraded Information of program 
code 

Reach-back Availability - User 
Capability to correspond with 
contractors on simulation issues 

Internet Availability - Access to 
documentation and information items 
through the internet 

Training Availability - Contractor 
supported training session provided 
to DoD agencies for employees 
professional development 

Feedback Loop - System in place to 
provide lessons learned, answers to 
current questions, and update center 
for users 


■ 

I 


Table 4 . 


Supportabilities Comparison Against W&A. 




Basic informational items are self 
explanatory and contain the simulation specifications. The 
more complex items like contractor support items were 
expanded in this section. The first was a reach back 
availability that pertains to the continued support of M&S 
in DoD throughout the life cycle process. The availability 
that was described in the hierarchy referred to contractors' 
use of simulations in parallel with DoD components for 
experimentation. The reach-back support line item was 
created for M&S application in military operations that 
required expertise of development experts for analysis of 
real-world scenarios. Simulations used in DoD to solve non¬ 
trivial processes may be relatively simple to contractor 
development entities. 

Exchange of program user information was 
common with use of the internet. Web site availability of 
M&S tools was included in Supportabilities. Simulations 
that were widely used in the DoD provided web site services 
to users for capabilities listed in Table 4. Copyrights and 
proprietary rights should not be a blocking factor for 
contractors in providing information to users that have 
access to simulations but not source code access. Web site 
availability was defined in this hierarchy as internet 
availability that provided an outlet to find operational 
information on simulations. Along with internet 
availability, there should be a feedback loop or method to 
give users the positive indications of progress assistance 
with challenges. This was in the form of observable 
simulation results or actual correspondence with 
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was to enable 


contractors. The goal of these "ilities 
users to understand and correct issues with operating M&S 
tools. 

Purchase of M&S systems often is accompanied 
with training for employees but training is not necessarily 
up to standards. Contractor provided training of M&S tools 
was invaluable to operating and analyzing military 
situations. DoD maximizes its investment in M&S with 
knowledgeable operators using simulations and systems to 
their full capacity. Ultimately, these support abilities 
contributed to the usability of a simulation. There were no 
measures to determine the level of support a contractor 
provided to the implementation of M&S; supportabilities were 
considered to possess the "ilities" if a single aspect were 
present. 

(2) Documentation. Use of M&S in DoD often 
relied heavily on how simulations were supported for 
independent modelers and decision-markers. Documentation 
for open source M&S was critical. There were essential 
forms of documentation that made the M&S tools considerably 
easier for use when included in simulation packages. The 
most common form of documentation was the user manual 
associated with the simulation. Documentation was defined 
in the capabilities hierarchy as any simulation that 


contained a 

link 

to the user manual 

within the 

running 

program. 

User 

manuals provided 

a complete 

set of 

information 

for 

operations of the 

simulation. 

Other 


publications, similar to the user manual, aided the user in 
M&S applications and uses and provided additional 
information. 
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Functionality tutorials were those 
informational programs within the simulation to facilitate 
the creation of models with developer's instruction and 
methods for proper set-up. This was defined as an 
instructional function in the simulation that assisted the 
user in step-by-step procedures to create a basic model that 
can then by personalized by the user for their specific 
requirements. Associated with tutorials was the use of help 
windows and pop-up information that rapidly provided 
assistance to users. 

The last element of documentation that was 
defined in the capabilities hierarchy was on-line support 
provided by contractors. These elements were considered a 
part of documentation because the information provided by 
the above elements was derived from the developers of the 
simulation. Online support from contracting companies, and 
specifically the developers, was consistent with referring 
to user manuals. This is another form of documentation that 
involved correspondence with live people vice documented 
information. 

2. User Interface 

M&S user interfaces must handle the needs of non¬ 
computer programmer users in DoD applications. The 
invention of the GUI has provided the capability for all 
users to interact with computer software. GUIs were an 
important functionality and considered vital to M&S 
applications. Along with GUI, there were "comprehensive 
ability" parameters that are DoD requirements for operating 
M&S tools. Operation of M&S tools meant that users be able 

to understand and work with symbols, programming language, 
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and results across difference branches and components of 
U.S. Armed Forces. Figure 9 shows the hierarchical 
structure for User Interfaces. 



Figure 9. 


User Interface Hierarchy Branches. 


a. Represent Abilities 

Represent abilities were the key for users to 
interface with simulations. It was divided into two traits; 
presence of GUIs, and "comprehensive abilities". The common 
GUIs in software are interactive windows with options 
available for users to select. Comprehensive able traits 
referred to the use of common terms and knowledge within 
simulations: Can a simulation be used by different users 
and obtain similar results? Representation is important to 
decision makers and modelers that attempt to use M&S tools 
in vastly different ways than initial design. The "ilities" 
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were critical to modeling advanced concepts that were not 
well defined for previous models like a SBE. 

b. Represent Abilities (GUI) 

There are common GUIs associated with the 
commercial operating systems. M&S users are familiar with 
common GUIs and can quickly adapt to a simulation with GUIs. 
The functionalities listed in the capability hierarchy were 
not a complete listing of GUIs. There was an understanding 
that there was no limit on interface options, however, this 
selection of items was presented to allow for a comparison 
of M&S tools in this research. There were two 
functionalities that were examined that made comparisons of 
simulations, input GUIs and set up wizards that were similar 
to tutorials. 

User input windows were found in virtually every 
software program. Input GUIs were defined to have four 
basic functions: pull-down menus, check boxes, typed in 
values, and adjustment varying sliders. Other GUIs that did 
not fit into these functions were recorded in the analysis 
of each simulation. 

The second function that was defined in the 
capabilities hierarchy was the presence of set-up wizards. 
A wizard was defined as the integrated instructional GUI 
that enabled users to create a model with the assistance of 
the simulation. This was included in a step-by-step 
instructions created by developers to build a skeleton 
model. The wizard assisted in modeling a specific process. 
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c. Represent Abilities (Comprehensive Able) 

"Comprehensive abilities" refers to the common 
application of simulation and their results across 
components of the DoD. There were two parts to 
"comprehensive abilities"; information availability and 
transferability. The amount and type of information that 
was displayed by a simulation was important to the user's 
understanding of model processes. Presenting accurate 
information was a capability that was considered in this 
hierarchy. The method in displaying information was 
measured in this analysis. There are three functionalities 
that were considered: the presences of (1) help menus, (2) 
pop-up information, and (3) user feedback information. User 
feedback information included messages that give status or 
completion indications. 

Transferability was defined similarly to the 
ability of simulation models used and interpreted by outside 
entities across a variety of users and user backgrounds. 
There were three functionalities that enable this ability: 
Common terminology. Standard Symbology, and Object 
templates. Simulations are under implementation 
restrictions dictated by DoD as set forth in Joint Pub 1-02. 
The set of general terms common to DoD were used and apply 
to M&S tools (DoD, 2001) . The use of symbology was not as 
common in DoD, each service has adopted its own standard 
symbols. Simulations were measured by the use of any 
standard set of symbology employed by the services. The 
last functionality in this trait was the object templates 
that referred to entities used in protocols like Distributed 
Interactive Simulation (DIS) and High Level Architecture 
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(HLA). Simulations were analyzed for the functionality that 
they could send information to other simulations based on 
the above protocol standards. Networking involves protocols 
with common entities that are predefined in Institute for 
Electronic and Electrical Engineers standards. DoD 
instituted the use of HLA in all simulations by the Under 
Secretary of Defense (Acquisition and Technology) in 1996. 
Object templates were incorporated into comprehensive able 
to illustrate simulations were integrated in multiple ways 
other than internet considerations. 

G. FLEXIBILITY 

Flexibility was defined as the ability of all levels of 
M&S users to use M&S tools for analysis. Flexible 
simulations were able to model different military 
applications and allow users to set model parameters to test 
a wide variety of outcomes in a timely manner. The first 
characteristic of a flexible simulation was the ability for 
it to handle a spectrum of functionalities that could 
represent real-world systems. Unfortunately, the level of 
flexibility was difficult to measure and had considerable 
variation. The amount of "model ability" needed was 
determined by elements of the specific model. BAA 05-020 
listed T-craft capability requirements, and was used as MOPs 
for "model ability" (ONR, 2005) . Figure 10 shows the 
hierarchical structure for Flexibility. 
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Figure 10. Flexibility Hierarchy Branches. 

The second characteristic of flexibility was stochastic 
processes in simulations that apply randomness to provide a 
sense of realism in outcomes. This randomness introduced 
the idea of chance and uncertainty into the planning phase. 
The T-craft concept was untested and required the full 
degree of uncertainty and randomness into its required 
capabilities. Simulation capabilities did not serve the 
interest of developing T-craft as a viable asset without the 
use of stochastic processes in simulations. Both of these 
characteristics contributed to effective use of M&S tools 
and enabled users to rapidly produce results. 

1. Model Able 

There are five "ilities" used to define "model ability" 
in the capability hierarchy that extend over a limited 
spectrum of functionalities used in M&S tools. This section 
is used to analyze the simulations' effectiveness in 

representing a system in M&S. These "ilities" ranged from 
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environmental effects to system parameters that included the 
ability to process classified material, input environmental 
databases, and scenario object representations. 
Adjustability contributed to being able to model a SBE and 
involved the basic system attributes. Other "ilities" 
referred to how the model was handling within simulations, 
resolutions of forces, and scenario environment. "Model 
ability" enabled simulations to render a real-world system 
in a constructive simulation environment. 

a. Securities 

Securities were defined as the safeguards of a 
simulation to handle information that may be present in DoD 
modeling. The advantage of using M&S was that it can 
provide insight to scenarios. These scenarios often 
contained secure information that may be sensitive in nature 
and require certain considerations. The single trait of 
simulation classification was defined as the ability to 
handle and safeguard secure information in accordance with 
DoD security regulations and instructions. All model 
scenarios used were unclassified. This trait was defined to 
allow greater range of the capability hierarchy that was 
applied across M&S tools. Simulations equipped with 
encryption and decryption devices added functionality and 
increased flexibility. 

b. Export/Import Abilities . 

Export/import abilities in M&S tools were defined 
as the ability to transfer scenario files from one 
simulation to another. The information extrapolated needed 

to be in a useful form as to enable cross simulation 
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interoperability. These "ilities" were an extension of 
program considerations in that data from other sources may 
be needed to model and simulate scenarios. The focus was to 
have M&S tools that had the capability to handle specific 
elements of available information be used to enhance 
simulation execution. There are different forms of model 
data that can be exchanged between simulations and were 
referred to as databases. Databases were composed of single 
entities that represented systems defined by users. They 
were also defined as the object files of the environment 
effects. Imagery data imported into a simulation was 
grouped in databases trait because the form taken by the 
information imported was in most cases a database object in 
the software. 


c. Adjust Abilities 

The majority of "model ability" in M&S tools came 
from having the ability to adjust parameters and settings of 
a model. Adjust Abilities are the user defined properties 
that represented the modeled system characteristics. This 
section was critical to physically representing a SBE in a 
virtual environment. The following traits were a collection 
of observed functionalities, not a comprehensive listing for 
M&S tools to be analyzed by. Figure 11 shows the 
hierarchical structure for Adjust Abilities. 
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Adjustab¬ 

ilities 



Figure 11. Adjust Abilities Hierarchy Branches. 

(1) Systems. System traits described in 
Table 5 were a limited scope of capabilities that M&S 
possessed. Simulations were measured on presence of 
functionalities and not performance. The capability 

hierarchy was defined to have the following system traits 
which include basic system properties. These were available 
for user to adjust as needed from model to model or 
situation to situation. 
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System Traits 

Functionality 

Definition 

Multiple Attributes 

Model properties that control actions of units based on 
resolution. Provide flexibility of users to model 
multiple interaction decision points. 

Model Basic Physics 

Interaction of model in simulation environment that effect 
movement and motion. SBE models needed to float in water 
and be affected by wind, sea state, and shore transitions. 

Refueling Capabilities 

Logistic requirements modeled to measure performance and 
usages. 

Movement Parameters 

Model scenario requirements specified and limit entities 
motion/actions in the simulation. 

Mode Selection 

Two modes of movement for a SBE model. Sea Mode and 

Hover. 

Clone / Copy Function 

The ability of an M&S tool to create copies or multiple 
entities with the same properties and attributes. Provide 
scalability of the model to increase SBE's used in a 
scenario. 

Military Operations 

For use in the DoD, M&S tools model joint operations and 

have capabilities to handle classic offensive and 

defensive actions. The following functionalities were 

defined in the hierarchy as military operations. 

Guard - Stay in position and protect units or area 
surrounding location. 

Patrol - Movement of entity to search and protect units or 
area surrounding designated location. 

Orbit - Continue repeated movement on designated path in 
any geometer shape. 

Attack - Perform actions to other entities to affect their 
status. 

Flee / Run -Detect an attack from a hostile force and be 
able to decide on withdrawing from the engagement 
based on user predefined limits. 

Grouping Functions - Multiple entities act together in un- 
nascence to perform a single goal. 

Inter Communications - Entities communication with each 
other during simulation. 

Remain in place - Entities ability to decide to remain in 
place or be directed to by attributes. 

Waypoint selection - User defined weapon selection. 

Unit operations - High resolution of entity actions that 
enable single units to act independently. Provides 

scalability to model. 


Table 5. System Traits Definition. 
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(2) Environment. Environmental factor 
starts to increase importance on "model ability" of T- 
craft's capabilities as greater forces are applied. The 
environment traits defined were not designed to limit M&S 
capabilities in other areas of simulation, but rather 
address factors on land, sea, and in the air with reference 
to a SBE. M&S tools were measured for presence of factors 
in this comparison study. 

There were three environmental traits defined 
in the capability hierarchy: terrain, ocean topography, and 
forces. The first trait, terrain, was at a minimum two 
dimensional (2D) that could model traditional warfare. 
There were three functionalities associated with terrain: 
surface configuration, natural and man-made feature 
representation. The ability of users to create a terrain in 
simulations was needed to develop custom scenarios. Surface 
configuration functionality enabled users to build and 
populate terrain surfaces with a variety of objects. Use of 
terrain objects were dependent on flexibility of the 
simulation to accept or create those program objects. These 
objects had the ability to be natural or man-made to present 
a realistic environment. 

The second trait, oceanographic modeling, 
applied to use of ocean depths that were needed in a naval 
environment. The ability to model contour depth data was 
used for the addition of submarine operations on the 
scenario. Water depth was also needed for operations of 
naval assets near the shore. M&S tools handled the case of 
ships running aground in shallow water. These points were 
eclipsed by the need of SBE's to shift from transit mode to 
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hover mode at certain ranges from the shore. Modeling the 
water features were used for T-craft to meet mode shifting 
requirements in the scenario. 

Third, M&S tools modeling SBE's were able to 
model sea state and wind effects within the scenario. Sea 
state was defined as the level of effects from water motion 
applied to T-craft movement and survivability. The wind was 
defined as the amount of force used to slow or push T-craft 
in the simulation environment. The capability hierarchy 
analyzed M&S tools for the presence of sea state and wind 
effects on entities. 

d. Measures of Performance 

Users were able to select and/or create MOPs 
within a scenario, which allowed for analysis of specific 
factors. Simulation results were likely to be used by 
decision makers to gain insights into system capabilities, 
thus enabled users to narrow their search in collection data 
methods. The three MOPs that were defined in the hierarchy 
correspond to Paragraph B, above. Simulations were 
determined to have an MOP "ilities" if the yielded output 
data was user defined measures that related to measures of 
survivability, transit times, and cargo transfer. 

e. Resolution 

The factors associated with the Basic and Advanced 
Scenarios called for a high resolution model. The level of 
resolution was measured as the capability to model T-craft 
force levels (Single vs. Multiple units) . The M&S tools 
used in this research were examined to determine what 
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resolution capabilities were present to see if a single unit 
was modeled with individual actions. Future scenarios may 
require the use of multiple SBE's with a high resolution. 
The "ilities" may be useful to decision makers in 
acquisition of SBE technology. 

2. Architectural Design 

Simulation program design was extremely important in 
the wide use M&S tools in the DoD. There are several design 
issues that must be addressed early on in the progression of 
an M&S tool to pertain directly to its usability. 
Standardization of functionalities is crucial for users to 
be able to understand simulation processes. Just as 
important as interface standards may be a background of 
simulation conception. DoD protocol requirements for M&S 
have put standardization of simulation at the forefront of 
M&S development. Interoperability of M&S tools enable 
higher levels of computation to be performed adding to 
application flexibility throughout M&S. Figure 12 shows the 
hierarchical structure for Architectural Design. 
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Figure 12. Architectural Design Hierarchy Branches. 


a. Federate Capable 

Federate capability was defined as "ilities" where 
simulations were integrated into a multiple code federation: 
A federate is a model networked into a HLA application (DoD, 
1998) . There are three traits that were derived from 
federations: current DoD regulations on M&S 
interoperability, reusability of models, and program 
history. M&S tools that were federation capable increased 
their use in DoD. This added to a model's flexibility to 
simulate SBE scenarios. The use of compatible simulation 
code allowed for the rapid exchange of information across 
M&S tools. Program history was simply defined as the access 
to dates and historical references to model uses. 

(1) High Level Architecture (HLA) . HLA is 
the standard protocol for DoD M&S. M&S tools were 
considered for the presence of HLA protocol, not merely 
computability. HLA is a strong measure of flexibility which 
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allowed for incorporation of M&S tools with DoD established 
models further validating the model, as well as the ability 
to import current models being used for analysis. 

(2) Reusability. Reusability was defined as 
the ability of a model to be recycled into future M&S 
capabilities. The development of M&S tools is costly and 
time consuming. Simulations like Combat XXI have reused 
existing code and modified it to fit into a federate that 
can then handle a boarder range of scenarios. This allows 
for further comparisons of traits among M&S in this 
hierarchy to determine flexibility. 

b. Program Considerations 

Given that M&S tools may handle secure 
information, an important consideration to architectural 
design was the flexibility of simulation features. M&S 
tools were measured on three aspects of programming. An 
inspection of six M&S tools was conducted to record if the 
programming code was open sourced or proprietary. This was 
important to understanding and believing the validity of 
simulations. The magic black box effect, where only inputs 
and outputs are handled without a clear understanding of 
underlying model algorithms and processes, does not assist 
DoD components if processes are not full accessible. The 
second trait was the capability of a simulation to input 
operational scenario data. This capability was used to 
decrease set-up and execution times. The ability of a 
simulation to import object libraries is a requirement to 
being HLA capable. Therefore, flexible simulations should 
possess both. The third was the auto-save and recover trait 

that also assisted in set-up and execution times. 
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3 . 


Stochastic Process 


Stochastic processes were defined in the capability 
hierarchy as simulation characteristics that were not 
deterministic. These processes were extremely difficult to 
describe and define, and were not limited to a narrow 
definition. This did not exclude the need to have 
simulations have stochastic characteristics. M&S tools were 
measured on how well the model allowed for entities to react 
to the scenario given movement and attribute inputs by 
users. Therefore, the only "ilities" that was listed under 
stochastic processes was script ability. The scenarios were 
dominated by naval operations which required special 
consideration to produce the proper outcomes. 

a. Scriptable 

Scriptable simulations were defined in the 
hierarchy as having abilities to simulate the model in the 
same method but obtained varying results. The Basic and 
Advanced Scenarios were based in the same environment, with 
the same routes and areas of operations. Having the same 
starting point was useful in analysis but problematic in 
deterministic simulations. There were four traits 
associated with script ability; user defined scriptable 
scenarios. Next-event models, time-step models, and random 
variables and/or Markov principles. Scriptable was defined 
as the ability of users to predetermine movement of entities 
by waypoint or attribute methods. 

(1) Next-event/time-step models. M&S tools 
fell into one of these categories, both of which had 
strengths and weaknesses. The trait was defined by the 


70 



simulation being either type. The properties of Next-event 
and time-step simulations provided the flexibility that SBEs 
scenarios utilize. 

(2) Random variables and/or Markov 
principles. By extension of stochastic, a simulation should 
posses some degree of randomness. This trait was defined as 
a simulation that had random variable to produce pseudo 
random actions within the iterations. Markov chains 
processes were made of random changes that depend on current 
states of the entities that entered a stable state. 

H. SCALABILITY 

Scalability was defined as the capability to regulate 
any given object's dimensions. Dimensions referred to the 
different functionalities of simulation in this context. 
The ability of an M&S tool to adjust to the conditions 
within the scenario was crucial to exploring the solution 
space. A scalable simulation enabled users to adjust force 
level parameters, as well force on force engagement. These 
two extremes often were not feasible, but certain degrees of 
freedom coincided with each other. The first characteristic 
of scalability was adjudication, which referred to the 
interactions of units with a given scenario. The user was 
able to select or adjust interactions of elements in the 
simulation to judge its importance to the results. Figure 
13 shows the hierarchical structure for Scalability. 
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The second characteristic, variation, pertained 
directly to resolution of a simulation. Variation in force 
levels were linked to scenario modeling and were often 
adjustable within scenario settings. SBE Simulation 
provided the user with the ability to vary resolution within 
the scenario along with providing controls for expected 
results. The adjustable traits of this characteristic that 
were used to define the capability of a scalable simulation 
are delineated in Appendix A. 

1. Variation 

Variation of M&S tools in the capability hierarchy was 
defined different than in traditional uses, such as 
statistics. This research utilized statistical analysis and 
referred to both terms. Variation characteristic was used 
as a method to control numbers of units and level of 
interaction in a scenario. M&S tools had two traits 
associated with user controls, adjudication and adjust 
abilities. The amount of scalability a simulation offers to 
decision makers could provide insights into possible 
solutions to capability gaps. 
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2 . 


Adjudication 


Adjudication was defined in the capabilities hierarchy 
as the methods to determine engagement status of entities 
during a simulation. Simulations offered the user the 
ability to determine and select adjudication methods. This 
included traditional probabilities tables, algorithm 
integration, and battle damage capabilities. M&S tools 
allowed for these interactions to be created and stored 
during simulation. As well as to determine engagement 
results, there was the ability to record and display them. 
This was a scalable "ilities" because its traits were 
adjustable. Figure 14 shows the hierarchical structure for 
Adj udication. 



Figure 14. Adjudication Hierarchy Branches. 
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Attain Abilities 


a . 

M&S tools were defined to be attainable if the 
following functionalities were available for users to adjust 
over multiple iterations. Attainable was, in the strictest 
sense, the internal workings of entities interactions with 
other entities. The first functionality was the ability of 
a simulation to calculate results of a scenario's outcome, 
which enabled the users to predetermine output data and 
collect it for analysis. This functionality was called 
Results and used data points that allowed for analysis of 
the scenario. These were representations of unit 
measurements, MOP translations, and battle damage assessment 
reports. MOP translation meant that the model parameters 
were interpreted in multiple ways. The second functionality 
was the availability of users to adjust engagement types of 
code in the model that governed the interaction of entities 
conducted in simulation iterations. The types of code that 
was accessible were probability hit and kill tables, sensor 
and weapon settings, indirect fire capabilities, sensor 
detection settings, and battle damage adjustment methods. 

b. Adjustability Traits 

The adjustability traits listed in variation are 
the same as described previously in the capability hierarchy 
under "model ability." 



V. 


SIMULATION MODELING 


Modeling & Simulation (M&S) is a power analysis tool 
used by all elements of DoD. M&S provides decision makers 
the ability to examine the SeaBase Enabler (SBE) in a 
virtual environment to test capabilities, operational 
impact, and influence on relief efforts. The requirements 
of SBE employment are discussed by those same decision 
makers as to what situation SBE could best be served. M&S 
tools were used to answer this question by modeling possible 
SBE scenarios. A model was specifically developed for 
representing the SBO to compare the various M&S tools that 
were available to industry and academia alike. The T-craft 
was used as a SBE for transportation of cargo to and from 
the SeaBase Operations (SBO). 

The approval of the T-craft to an acquisition program 
may rely heavily on the role M&S plays in evaluating the 
SBE's capabilities in given scenarios. The SBE model 
developed was used to compare M&S tools capabilities to 
determine simulations usability, flexibility, and 
scalability. The scenario utilized the baseline 
capabilities for T-craft to define model parameters. The 
M&S tools provided performance data, which could be given to 
developers and decision makers alike. The diversity of 
individual M&S tools was considered in initial simulation 
selection over individual M&S tool capabilities. 
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A. SBE SCENARIOS 

There were two scenarios types, Basic and Advanced, 
that were created in this study to address T-craft 
requirements; peace and war time environments. The peace 
time environment was modeled without the presence of hostile 
forces to allow T-craft free transit. This was called the 
Basic Scenario and enabled M&S tools to collect MOPs data on 
T-craft's capabilities. The war time environment introduced 
hostile forces to the measure survivability MOP. This was 
referred to as the Advanced Scenario. Between the two 
scenarios, a wide scope of application was designed for the 
model to deal with SBE real-world projected scenarios. 

There were four real-world scenarios in which the SBE 
concept is projected to have direct involvement. First, 
Peace Keeping and Peace Enforcement Operations (PKO) in a 
peace-time setting are defined by Milan Vego as the 
principle peace operations. These operations are designed 
to control and eliminate hostilities using force and regain 
or maintain peace. The timeframe is nominally after the 
conclusion of major theater war (Vego, 2007). This is also 
keeping in mind that all countries have reached an agreement 
of ceasefire. Second, Major Theater of War Combat 
Operations is the series of tactical battles that are used 
to achieve operational objectives. Actions are often 
conducted parallel or sequential in accordance with the 
operational plan (DoD, 2001) . 

Third is Regional Crisis Intervention Operations that 
are commonly centered on a single nation's objective or 
security. This is a situation that develops quickly. 


creating the need for diplomatic, economic, political, or 

76 



military resources. The resources are used to divert the 
crisis and reestablish stability. These operations are 
normally associated with low threat risks to forces. 
Lastly, there is Stability Operations that include military 
missions, task, and activities that occur in conjunction 
with other nations. They are deployed to provide security, 
services, and relief to host nations during times of 
conflict (DoD, 2001) . A generic model was developed to 
encompass elements from these four operational concepts. 
The Basic and Advanced Scenarios were designed to input the 
generic SBE model in a series of simulation tools to compare 
their capabilities. This evaluation was based on the 
previously defined hierarchy. 

B. T-CRAFT MODEL 

T-craft capabilities were modeled like that of current 
amphibious landing craft transferring cargo from the area of 
SBO to shore landing sites. The T-craft concept is being 
developed in the vision of current amphibious transportation 
craft capabilities with a call for technology to increase 
key performance parameters. T-craft is projected to offer a 
wider scope of operations (by being able to transit 500 nm 
at 40+ knots) than current logistic crafts are not able to 
fulfill. This is a capability that may provide options for 
military planners in both non-hostile and hostile 
environments. T-craft also provides the capability of 
transiting from debarkation point fully loaded. These 
capabilities are truly game altering. They are significant 
challenges to analysts and developers comparing SBE's 
against current capabilities. 
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The T-craft model was designed to make cargo parameters 
flexible, as well as for a time component to measure transit 
times. The generic model also attempted to measure the 
scalability of simulations within M&S tools by introducing 
hostile threat interactions and engagements. Figure 15 
shows the battle space for the T-craft scenario that was 
modeled. The area represented the Sea of Japan with the 
separation between land masses as approximately 500 nm at 
the widest point. This location was selected based on the 
availability and model set up of debarkation points along 
the western coast of Japan. 



Figure 15. SBE Modeled Battle Space. 
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C. BASIC SCENARIO 

The Basic Scenario was based on Regional Crisis 
Intervention Operations. The SBE mission was designed to 
provide relief aid (cargo) and other supplies to ground 
forces operating on a peninsula region near the coast. The 
debarkation point was notionally a sea port which 
corresponds to Sasebo, Japan. A debarkation point is a 
logistic hub where SBE are loaded with cargo for heavy 
transfer. The transit to the SBO was approximately 350 to 
400 nautical miles (nm) . The battle space characteristics 
were designed to test the T-craft high speed transit 
capability. 

The Basic Scenario modeled a simple transit with two 
phases. The first phase was T-craft transiting from 
debarkation point to SBO area. The second phase was from 
the SBO area to a landing site on the northern part of the 
peninsula. The T-craft model used was the same as industry 
prototypes that created a craft with desired capabilities 
and no self defense. The Basic Scenario was designed to 
determine a baseline for transit times and cargo load-outs 
that were used to compare against in the Advanced Scenario. 

1. Non-Hostile Operations 

T-craft's transit in the first phase was designed to 
have no external forces acting on it. The Regional Crisis 
Intervention Operations provided the scenario set up that 
enabled T-craft to transit to the SBO area without the 
threat of hostile forces or interference. Given the 
regional make up of the Sea of Japan, the assumption that T- 
craft could transit un-escorted and uncontested was valid. 
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The T-craft was able to transit while loaded or unloaded and 
varied transit speeds to allow for separate baseline 
measurements in multiple iterations. The experiment design 
offered independent measurements of these factors to 
possibly observe relationships between further studies. 

2. Interactions 

The interaction of T-craft with the shore line is a 
significant physical problem being experienced by 

developers. T-craft capabilities are required to carry 
large amounts of cargo and equipment but design 
considerations are limiting landing capabilities. The T- 
craft is projected to be able to land on shore lines that 

are less than 2 percent incline. The scenario used in 

this study assumes there is sufficient shore line 

supportability on the landing site on the peninsula. 

3. Cargo Transfer 

Cargo transfers in amphibious operations and in the SBO 
have loading spot considerations that affect MOPs. This 

required waiting queues or time delays in the scenario 

model. Time-step and DES handled this delay in different 
ways causing a variation in the Basic Scenario baseline 

measurements. The variation in simulation results were 
assumed to not affect the comparison of M&S tools based on 
the definition of the capabilities hierarchy. 

4. Refueling Requirements 

The number of factors associated with any given 

scenario was exponential with the depth of detail presented. 

A major factor of military operations is the logistical 
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support needed by units in the field. T-craft logistical 
requirements were assumed to have been adequate. Fuel 
requirements were assumed to be sufficient for transits and 
transfers in both phases of the scenario, and that fuel 
levels were not modeled for unit movement usage. This was 
critical for M&S tools like MANA that have no resource 
measure capabilities and fuel levels were adapted to be used 
as cargo levels. 

D. ADVANCED SCENARIO 

Non-hostile environments were ideal for operation but 
not without the need for tactical protection. The Advanced 
Scenario was based on PRO and Stability Operations that 
presented a battle space that had the potential for conflict 
within the region. Political tensions could present a 
possible SBE situation on the peninsula. The robust range 
of operations that were possible for the area used both an 
Advanced and Basic Scenario to measure MOPs key to 
evaluating SBE performances in a simulation. 

T-craft is being developed with limited defense 
capability and is susceptible to attack from the air and 
surface. The Advanced Scenario introduced hostile threats, 
using the Basic Scenario as the starting point. Surface and 
air threats were inserted into the first phase to intercept 
T-craft in the first phase and during SBO transfer. Escort 
ships and aircraft were in direct response to T-craft's lack 
of self defense capabilities. T-craft was escorted by 
varying number of warships. Escort's areas of operations 
were focused on protecting T-craft in high threat regions 
(first phase) of the scenario. The second phase was 
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relatively unprotected by escorts while T-craft commenced 
high-speed runs into the landing site. 

1. Escort Requirements 

There were three surface escorts modeled that were 
assigned to provide protection to the T-craft during transit 
and cargo transfer in and around the SBO area. This is 
where the hostile forces were generated and modeled to 
patrol. The escort forces were varied from a single escort 
up to a total of three during specific runs. The number of 
hostile forces was also varied from a single surface ship or 
aircraft up to a total of three surface and two aircraft 
threats. This design allowed for a robust design of 

experiments to be utilized in the simulating the model over 
multiple iteration. The varying of forces was used as a 
proof of concepts in the MANA simulation. 

2. Interactions 

The interactions of friendly escorts in the Advanced 
Scenario were modeled with superior capabilities. U.S. 
forces were assumed to have valid overwhelming capabilities 
compared to regional threats. The other interaction was 
threat areas of operations that limited hostile forces 
movement. The high threat was assumed to be a general 
approximation to where they originate from and not where 
they remain during simulation runs. This assumption was 
clearly observed in time-step models with agent based 
models. 
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3. 


Combat Survivability 


Combat survivability was highly variable based on 
simulation settings. The critical aspect of measuring 
survivability was that it could be user defined and that the 
option was available. The Advanced Scenario introduced this 
MOP by adding hostile forces to the model. The assumption 
for combat survivability was that the damaged sustained by 
T-craft was probabilistic and not constant across M&S 
models. The standardization of probability tables or 
adjudication methods was not addressed in this research. 
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VI. RESULTS ANALYSIS 


This chapter presents simulation parameters of the six 
M&S tools used for modeling a SBE. The SBE Scenario was the 
basis for all models and was implemented in slightly 
different ways depending on the capabilities of the M&S 
tools used. The SBE Scenario issues, like collection of 
MOPs, modeled entity interactions, and graphical interfaces 
that were discussed in the previous chapter sections. This 
chapter listed the SBE Scenario model parameters for MANA, 
Pythagorus, NSS, and Simkit that were directly used in the 
course of my research. JCATS and Arena model results were 
used for comparison only, with no formal stating of model 
parameters. The M&S models created were functionally 
operational, with every effort made to present complete 
models. However, this research comes with a disclaimer that 
this was the best attempt by a master's degree student to 
build models for thesis work. 

A. CONCEPTUAL REPRESENTATION 

The reproduction of a SBE Scenario in a computer based 
model provided the evidence needed to evaluate each M&S tool 
used for modeling. In both types of simulations (time-step 
and next-event) the SBE Scenario was modeled in relatively 
similar ways. This included a SBE craft, escorts, and 
hostile forces. Variations in M&S tools did not allow for 
parameters of one model to be emulated exactly in every 
model, but did allow for a comparison across simulations of 
capabilities. Two models, MANA and Simkit, provided data 
for MOPs, with limited collection and analysis efforts. 
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Other M&S tools were merely observed to have the capability 
to produce MOPs. Because data collection was not the focus, 
it was assumed to be similar for the remaining simulations 
within the given types. This section details the 
differences in implementation of the SBE model. 

1. Survivability of T-Craft 

The survivability of T-craft in the SBE Scenario relied 
heavily on the scalability of each model. The adjudication 
"ilities" in the capability hierarchy was used to compare 
how models attain abilities varied in simulating the T-craft 
in the scenarios and if survivability was affected by 
differences in adjudication controls. Table 6 lists the 
similarities between M&S tools. 
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Capability Hierarchy 

MANA 

PYTH 

JCATS 

NSS 

Simkit 

Arena 

Scalability 







Adj udication 







Attain ability 








Results 








Units of Measure 

D* 

s 

s 

S 

s* 

s* 


MOP Translation 

S* 

s* 

D 

D 

D 

D 


User Defined Data 

S 

s 

S 

D* 

S 

S 


Battle Damage 

s 

s 

S 

S 

S 

S 


Engagement (Access by 

the User) 








Probability Tables 

s 

s 

D* 

D* 

S 

S 


Sensor & Weapon 

s 

s 

D* 

D* 

s 

s 


Indirect Fire 

s 

s 

D* 

D* 

s 

s 


Sensor Detection 

s 

s 

D* 

D* 

s 

s 


Battle Damage 

D 

D 

D 

D 

D 

D 

D - Difference in M&S tools used. 

D* - Difference in M&S tools in same type. 

S - Similar to other M&S tools used. 

S* - Similar to other M&S tools in same type. 


Table 6. Simulation Similarity Comparison. 


2. Graphic Representation 

There were three different representations of the SBE 
Scenario that were available across the types of 


simulations. 


The first was the 


classic sand box 





representation that JCATS and NSS depicted with blue water 
and brown colored land. This was the traditional look of 
M&S tools with which decision makers are probably most 
comfortable. JCATS and NSS also had model controls on the 
same screen as the battle space for the user to visualize 
adjustments. This was completely different from the other 
models like MANA and Pythagoras that offered separate 
control windows for agent attributes. The other difference 
in simulation with MANA and Pythagoras was that waypoints 
and other control options remained on the screen during 
iterations of the model. The last difference was that 
Simkit and Arena models did not offer any battle field 
depiction for users. These differences greatly affected 
capability hierarchy evaluations of the M&S tools. 

3. Agent Based Modeling 

Use of AABM was observed in four of the six simulations 
with Simkit and Arena having no capability. MANA, 
Pythagoras, JCATS, and NSS had AABM elements that enabled a 
stochastic process within the simulations. While JCATS and 
NSS used AABM algorithms for agent actions, MANA and 
Pythagoras had AABM built in to govern actions of their 
entities in the form of attribute settings. The SBE 
Scenario was modeled in both MANA and Pythagoras with 
similar settings but could not be duplicated. The attribute 
settings were used at a minimum to obtain results as the 
evidence that the different M&S tools did have the 
functionalities. MANA and Pythagoras models were different 
even though the modeled attributes for the T-craft entity 
were held relatively constant. 
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4. Deterministic Attributes 

Deterministic attributes were meant to describe the 
probability based models. Simkit and Arena were models that 
had no agent elements but offered probabilistic results to 
the SBE Scenario. These models were limited to modeling the 
scenario in DES. The models were not deterministic by 
definition but could be repetitive over multiple iterations. 
The other differences with DES models were that the scenario 
focused on the processes within the scenario that the other 
four models were not capable of modeling or measuring. DES 
models modeled the delay interactions of the T-craft as it 
moved from one point or process to another. Simkit and 
Arena modeled the loading and unloading of T-craft in the 
SBO and the shore landings site, where other M&S tools 
inserted constant delays. DES's capability to 
stochastically model the interaction characteristics made 
the SBE Scenario narrower in scope compared to the full 
scenario models. 

5. Simulation Start 

Time and events were measured differently for both 
types of M&S. Time-step based models enabled MOPs like 
transit times and survivability where next-event based 
models isolated cargo transfers, which made the SBE 
Scenario, vary across M&S. The start of simulations was the 
only time in which the parameters were constant. DES models 
applied probabilities where designed, during every 
iteration. AABM applied probabilities when the agent 
selected the path to engage T-craft. The stochastic 
properties of the M&S tools caused the SBE Scenario to 
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unfold rather quickly into multiple directions that could 
not be accounted for in data analysis. The M&S tools 
selected did provide a wide range of capabilities that were 
available. 

B. TIME-STEP BASED 

Time-step based models were centered on processing 
events that occurred at a given time interval. The updates 
were made to the simulation after a process cycle of all 
events had been calculated and was complete. Time-step 
based models processed all events at every time interval and 
sent updates as needed. Time-step enabled such models as 
AABM to recalculate search algorithms on demand in a 
stochastic environment. The process time grew as more 
complex events were added to the model. 

1. Joint Conflict and Tactical Simulation 

The model used in evaluating the capabilities of JCATS 
was created by LT Richard Jimenez, U.S. Navy, at the Naval 
Postgraduate School in the System Engineering department. 
Together with LT Jimenez, the SBE Scenario was the basis for 
implementation of his SBE Scenario into JCATS assessment 
that was referenced in my research. Additionally, his work 
was designed to provide a baseline model for the SBE 
Scenario to test concept of operations ideas that would be 
used in further data analysis. The Jimenez Scenario was 
based on the geographical east and west coast of the Korean 
peninsula and was modeled in a regional conflict setting. 
The bulk of the research was focused on T-craft's 
survivability in the SBE Scenario; therefore, the Basic 
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Scenario was not simulated due to time constraints with 
iteration times of the JCATS model. 

The major difference in the Jimenez scenario was the 
use of multiple T-craft entities within the simulation to 
increase survivability measurements. JCATS was well suited 
for theater level simulations at a high resolution. 
Modeling a single T-craft was not effective for JCATS. The 
T-craft was modeled with a higher resolution. Future work 
in JCATS could experiment with the resolution as a resource. 

a. Parameters 

The Jimenez Scenario used entities built from 
entities within the JCATS database. Air superiority was 
assumed in the scenario; hence, there were no air units 
modeled. Escort units were modeled as cruiser and destroyer 
platforms and SBO units were modeled as standard amphibious 
platforms. Extra considerations were taken because of JCATS 
modeling requirements to properly create a working model. 
The first assumption was that logistic support was available 
without special implementation. U.S. Naval auxiliary 
platforms were modeled into the Jimenez Scenario to provide 
fuel and cargo for transfer to the shore by T-craft from the 
JCATS database. 

Hostile forces were modeled as foreign destroyer 
and coastal patrol platform vessels as well as ground 
forces. The ground conflict of the model was not discussed 
in this study because the measurements of the T-craft were 
collected prior to ground conflict occurred in the scenario 
and therefore did not affect interactions at sea. The 
initial settings of the Jimenez Scenario started with a sea 
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state of 1 at night with a full moon, with weather effects 
at a minimal, and hostile force capabilities set to 10 to 15 


percent less than Escorts. Figure 16 displays the Jimenez 
Scenario at simulations start. 
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Figure 16. Jimenez Model Scenario at Simulation Start. 


b. Design of Experiments 

The Jimenez Scenario focused on employment of the 
joint force capability to project power from the sea to the 
shore. Attributes that were varied were environmental 


92 






conditions and distance from shore landing sites. Table 7 
illustrates the simulations configuration that was 



Table 7. JCATS Simulation Design of Experiments. 


c. Data Analysis 

The results of the Jimenez scenario showed the 
capability of JCATS to analyze the SBE scenario in a 
different way than other M&S tools used. The JCATS modeled 
the dual coastal approach of forces, which measured 
logistical elements automatically within the scenario. 
JCATS also represented environmental conditions differently 
than NSS that allowed for measurement of transit times. 
Specific data points were extracted on surface tactic 
implementation that were outside the scope of the Advanced 
Scenario but proved to show the flexibility of JCATS in the 
evaluation. Table 8 shows the results of the simulation 
runs conducted by LT Jimenez. 
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JCATS Simulation Results 

MOP 

Scenario 1 

Scenario 2 

Mission Duration 

West 

East 

West 

East 

West 

Transit to shore 

landing site 

* 

* 

7:58 

9:05 

9:48 

Transit back to SBO 

* 

* 

13:20 

18:50 

16:21 

Survivability 

West 

East 

West 

East 

West 

Percent of T-craft 

survived complete 

runs 

4 % 

0 % 

100 % 

96 % 

96 % 

* No times recorded based on T-craft survival rate in transit to shore landing 

site. 


Table 8. JCATS Simulation Results. 


2. Map Aware Non-Uniform Automata 

MANA was developed by a New Zealand company Defense 
Technology Agency (DTA) in 2008 as an agent-based model with 
a bottom-up approach to warfare. DTA researched 
implications of chaos and complex theory in military 
applications and discovered that cellular automaton models 
produced results that were different that those of 
traditional models. The limitations of traditional models 
with areas like command and control, situational awareness 
(SA), and heterogeneous forces fell short of realistic 
results. The MANA program was designed to introduce certain 
functionalities to the current Complex Adaptive Systems 
(CAS) simulations. MANA integrates a memory map to allow 
for agents to have share SA and maneuver around the battle 
space (McIntosh, Anderson, & Lauren, 2007). 
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In 2000, MANA, with the Project Albert, a U.S. Marine 
Corp. research development program, introduced three agent- 
based models in succession: Irreducible Semi-Autonomous 
Adaptive Combat (ISAAC), Enhanced ISAAC Neural Simulation 
Tool (EINSTein), and Pythagoras (Bitinas, Henscheid, & 
Troung, 2003) . The agent-based characteristics made MANA 
the most appealing of the AABM where results could be 
obtained. The bulk of the model settings were in the 
attributes of each entity. Event triggers were also 
implemented to assist in interactions of units to obtain the 
proper MOPs. The Advanced Scenario attempted to reflect 
controlling sea lanes of communications by defending against 
a hostile threat with varying forces. The sea lanes were 
limited to waypoints in the first phase of the scenario. 

There were many assumptions in this scenario that 
allowed the SBE to be modeled. The fuel function in this 
study was used to model cargo transfer from the T-craft 
entity to landing sites. Refueling and logistic support 
were assumed to be adequate and not measured. The Advanced 
Scenario did not actively use coordinated tactics by either 
sides. The use of MANA produced stochastic results to 
answer survivability questions posed by scenario objectives. 
MANA has a number of available parameters like preference 
settings towards enemy and friendly units that were 
adjustable for modeling realistic interactions. 

Resolution was an important aspect in MANA for MOP 
studies where cargo was the focus of a study. This research 
used MANA because of its resolution ability of combat 
forces. The Advanced Scenario was designed with opposing 
forces and one T-craft transiting to the SBO area. Future 


95 



studies many be modeled with multiple SBE being used to 
transfer cargo. The last assumption that was made was the 
modeled capabilities of forces. The Scenarios depicted U.S. 
Naval Forces as escort elements and a generic third world 
naval force as the opposing force. All opposing forces were 
modeled with a limited offensive capability. Escort forces 
were modeled with a 2:1 advantage in the Advanced Scenario. 

The results of the Basic Scenario were as expected; 
however, the Advanced Scenario introduced a higher degree of 
stochastic processes and did not clearly provide statistical 
MOPs for survivability. The AABM elements appeared to 
contain more randomness that could be accounted for in 
attribute settings. Another MOP was the number of escorts 
needed for T-craft defense. Based on the irregular results 
of the survivability measurement, the number of escorts did 
not correlate to the increase in opposing forces. A future 
consideration could be convoy tactics to ensure that the 
transfer of cargo is sufficient. The protection of cargo 
ships in naval history could have had applications in this 
scenario where the amount of supplies delivered was a 
measured factor. 

a. Parameters 

The scenario parameters in the MANA model are 

depicted in the following section. There were six 

attributes and one general setting tab within MANA that were 

used to set parameters for both the Basic and Advanced 

Scenarios. The tabs were Battlefield settings. General, 

Personality, Ranges, Sensors, Weapons, and Algorithm. 

Figures 25 through 43 show the SBE model set up in the MANA 

environment at the end of the chapter. Figure 17 is the 
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generic model set up for the battle space configuration and 
a depiction of the Advanced Scenario. The model dimensions 
were configured to match the approximate area span of the 
geographical location; the scenario was based on a 500 x 500 
nm area. The terrain parameter was kept as a simple line of 
sight model that provided the most general mode for 
evaluation purposes. The remaining settings were left as 
default. 



Figure 17. MANA Battlefield Settings. 

The first unit instance defined in the Scenarios 
was the T-craft. Figures 25 through 29 show T-craft 
settings used in the Basic and Advance Scenarios. The 
number of T-craft units remained constant at one for all 
simulation runs. T-craft waypoint flags are seen in Figure 
17 . T-craft weapons tab was not provided due to the INP 
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requirements that do not call for defense capabilities. The 
weapons tab had Master Enable deselected. 

The second unit instance defined was the escort 
forces for T-craft's transit to the SBO in the first phase. 
The number of escort forces varied according to the design 
of experiments. The attribute settings were kept simple as 
well for the same reasons. Figures 30 through 33 show the 
escort parameter settings that were the same for each 
individual escort unit. The general configuration settings 
for escort units used the side name as Escorts, Squad #3, 
and varied the number of agents. The initial orientation 
was designed to remain constant for all entities. 

The third unit instance was hostile surface 
forces, which are represented in Figures 34 through 38. The 
same general configuration was used as Escorts with the 
naming of hostile forces. The fourth unit instance was a 
hostile air threat that was modeled with considerable 
advanced capabilities over surface forces. This advantage 
was represented by increased speed capability. Figures 39 
through 43 show the hostile air threat model parameters. 
Squad # 6 was used and the side options were selected to 
match those of the hostile surface forces. The last 
parameter that was selected was the simulation stopping 
criteria. This parameter was set to T-craft's end goal. 

b. Design of Experiments 

The solution space for the model was large and 
required extensive analysis of data to examine all possible 
combinations. According to Cioppa (2002), the concept of 
Latin hypercubes with orthogonality improved space filling 
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properties of experimental design. The application of nearly 
orthogonal Latin hypercubes (NOLH) reduced experimental 
iterations to find key correlation elements of a simulation. 
The NOLH method was applied to decrease the number of 
iterations needed to determine relations between the three 
MOPs . 

There were three factors in the Basic Scenario 
that were varied. The first variable was speed of the T- 
craft which was represented in MANA as an arbitrary factor 
within the model. MANA provided for the selection of two 
speeds for the T-craft entity. The second speed was double 
the first to show the capability T-craft had to achieve in 
capability 3. The additional factor was the number of 
transfer trips scripted to the shore with a maximum of three 
for the T-craft to delivery cargo in the second phase. 
Table 9 shows the NOLH design employed for the Basic 
Scenario. A single variable setting or trail was iterated 
for 50 replications. 
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Basic Scenario 

First Phase 

Second Phase 

Speed 

Cargo Rate 

Speed 

Cargo Rate 

Trips to 
Shore 

200/100 

-20 

200/100 

-20 

3 

200/100 

-10 

200/100 

-10 

3 

200/100 

-10 

200/100 

-10 

1 

200/100 

-15 

200/100 

-15 

2 

400/400 

-20 

400/400 

-20 

2 

400/400 

-10 

400/400 

-10 

2 

400/400 

-10 

400/400 

-10 

3 

400/400 

-20 

400/400 

-20 

3 

400/400 

-15 

400/400 

-15 

2 

400/400 

-5 

400/400 

-5 

1 

400/400 

-15 

400/400 

-15 

1 

400/400 

-15 

400/400 

-15 

3 

400/400 

-10 

400/400 

-10 

2 

200/100 

-5 

200/100 

-5 

2 

200/100 

-15 

200/100 

-15 

2 

200/100 

-15 

200/100 

-15 

1 

200/100 

-5 

200/100 

-5 

2 


Table 9. NOLH Design of Experiments for Basic Scenario. 


The Advanced Scenario introduced varying numbers 
of escort and opposing forces to T-craft's transit. In an 
effort to counter the opposing forces, escort ships were 
positioned ahead of T-craft's transit, which allowed for 
protection of the transit, as shown in Figure 17. Expanding 
on Table 9, Table 10 shows the factors used to simulate the 
SBE model in both phases. 
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Advanced Scenario 

Speed 

Cargo 

rate 

Trips 
to shore 

Escorts 

Surface 

Threats 

Air 

Threats 

200/100 

-20 

3 

2 

2 

2 

200/100 

-10 

3 

2 

1 

1 

200/100 

-10 

1 

2 

2 

2 

200/100 

-15 

2 

3 

2 

1 

400/400 

-20 

2 

1 

2 

1 

400/400 

-10 

2 

3 

1 

2 

400/400 

-10 

3 

2 

3 

1 

400/400 

-20 

3 

3 

3 

2 

400/400 

-15 

2 

2 

2 

2 

400/400 

-5 

1 

2 

3 

1 

400/400 

-15 

1 

2 

3 

2 

400/400 

-15 

3 

3 

2 

1 

400/400 

-10 

2 

1 

2 

2 

200/100 

-5 

2 

3 

2 

2 

200/100 

-15 

2 

1 

3 

1 

200/100 

-15 

1 

2 

1 

2 

200/100 

-5 

2 

1 

1 

1 


Table 10. NOLH Design of Experiments for Advanced Scenario. 


The representation of transferred cargo was 
modeled in MANA by using triggers that simulated the 
increase of goods at the shore landing site. The shore 
landing site enabled a trigger when T-craft was within range 
and triggered the commencement of cargo transfer. My Fuel 
Usage Rate simulated large amounts of cargo transfer. These 
parameters were in shown in Ranges Settings when the Fuel 
Out trigger was selected. 

c. Expected Results 

The expected results in the Basic Scenario were 
predicted to be straight forward measuring the statistical 
outcomes of transit times and cargo transfer. The 
survivability of T-craft in the Advance Scenario was 
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affected by the increased stochastic processes. The third 
measured value was the number of escorts needed to provide 
protection to the T-craft unit. This was proportional to 
the number of hostile forces in the area. 

d. Data Analysis 

MANA provided MOPs in generic terms, which allowed 
for a capabilities evaluation of the simulation to be made. 
The representations of time and cargo values did allow for a 
translation to various units and measures. The generic 
units were reported to illustrate the versatility of the 
simulation for combat models. The survivability factor of 
T-craft in the Advanced Scenario measured a probability of 
survival. The results were provided here to illustrate the 
capability of MANA to yield MOPs. 

The following results were obtained from the Basic 
Scenario and list the average transits times with varied 
number of deliveries based on the design of experiments. 
The average amount of cargo transferred to the shore site 
was listed by varied rate transfers. Again, all trials 
conducted in MANA were replicated 50 times for statistical 
analysis. Table 11 shows the results from the Basic 
Scenario. 
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Basic Scenario Results 

Speed 

Cargo Rate 

Time + SD (sec) 

Cargo + SD 
(gal) 

200/100 

5 (3 Trips) 

457.84 + 8.29 

398.60 + 177.27 

200/100 

10 (3 Trips) 

445.38 + 7.30 

1173 + 316.74 

200/100 

20 (3 Trips) 

446.38 + 8.48 

2295.2 + 780.76 

400/100 

10 (3 Trips) 

200.04 + 4.78 

465.0 + 148.07 

400/100 

15 (3 Trips) 

201.20 + 5.77 

702.10 + 253.51 

400/100 

20 (3 Trips) 

200.5 + 4.81 

893.6 + 253.51 

200/100 

5 (2 Trips) 

347.76 + 5.04 

364.4 + 110.3 

200/100 

5 (2 Trips) 

336.4 +4.90 

328.70 + 108.78 

200/100 

15 (2 Trips) 

338.36 + 5.21 

1001.4 + 331.11 

400/100 

10 (2 Trips) 

160.82 + 3.55 

295.8 + 117.21 

400/100 

10 (2 Trips) 

167.76 + 4.52 

325.2 + 126.59 

400/100 

15 (2 Trips) 

157.72 + 3.50 

441.6 + 180.87 

400/100 

20 (2 Trips) 

164.1 + 3.94 

558.0 + 168.85 

200/100 

10 (1 Trips) 

283.28 + 13.81 

331.2 + 131.59 

200/100 

15 (1 Trips) 

280.84 + 13.17 

542.4 + 291.47 

400/100 

5 (1 Trips) 

136.32 + 1.63 

97.6 + 33.12 

400/100 

15 (1 Trips) 

134.96 + 2.09 

307.20 + 138.15 


Table 11. Basic Scenario Results. 


Table 12 shows the results from the Advanced 
Scenario which lists the distribution of survival percent 
for T-craft in the given replications. The distribution of 
Surface and Air threats represented the number of entities 
that were built into the scenario run for each category. 
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Advanced Scenario Results 

Speed 

Cargo 

Rate 

Escorts 

SURF 

Threat 

AIR 

Threat 

Survive % 

200/100 

20 

3 

2 

2 

62 

200/100 

10 

3 

2 

1 

48 

200/100 

10 

1 

2 

2 

52 

200/100 

15 

2 

3 

2 

48 

400/100 

20 

2 

1 

2 

80 

400/100 

10 

2 

3 

1 

54 

400/100 

10 

3 

2 

3 

68 

400/100 

20 

3 

3 

3 

70 

400/100 

15 

2 

2 

2 

74 

400/100 

5 

1 

2 

3 

64 

400/100 

15 

1 

2 

3 

84 

400/100 

15 

3 

3 

2 

50 

400/100 

10 

2 

1 

2 

90 

200/100 

5 

2 

3 

2 

42 

200/100 

15 

2 

1 

3 

76 

200/100 

15 

1 

2 

1 

54 

200/100 

5 

1 

1 

1 

64 


Table 12. Basic Scenario Results. 


The mean probability of survival for T-craft was 
63.53 + 14.06%, which was less than 80 percent of an 

acceptable survivability rate. 

e. Select Capabilities 

Use of the MANA program showed that it was 

possible for the SBE Scenario to be represented in a 
computer-based model. MANA provided a set of 

characteristics and parameters in the form of personal 
settings that were used for modeling the T-craft to explore 
the capabilities that were desired for a SBE. Desired 

results were obtained from fairly simple agent settings, 
which made it user friendly. The graphical representation 
provided a powerful capability for visualization of the 
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battle space. MANA was a stand-alone agent-based M&S tool 
that could be used in combination with a federation, for 
future T-craft simulation. 

MANA was useful for collect data from the model. 
The data obtained from the replications of Scenarios were 
directly measured to determine statistical information. The 
results were used to show the presence of an accuracy 
functionality. The Basic Scenario results indicated an 
apparent relationship between the increased transfer rate 
and speed. One limitation to the MANA results was that for 
11 of the 17 measurements, there was a large amount of 
variability among the cargo transfer time, such that the 
standard deviation values were as large as half of the mean 
values. Typically, a modest amount of variability would be 
indicated by a standard deviation that is less than 20 
percent of the mean value. 

MANA is not an open source program. A 
disadvantage of this was that documentation was not 
available to users. The MANA user manual was available 
within the downloaded source code, but was outdated for both 
MANA version 4 and version 5. There were several display 
and control settings that did match and were not explained 
in the user manual. This was only a minor inconvenience. 

One difficulty to building the SBE scenarios was 
the determination of weapons effectiveness and defensives 
for forces that allowed for favorable exchange rates, while 
applied red force movements were realistic. The other 
difficulty was modeled T-craft capabilities had to be 
maintained to conform to desired ONR requirements. The T- 
craft speed was overly extended to illustrate the extreme 
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advantage it had over conventional forces. This was done by 
setting T-craft's speed to double that of hostile forces. 

One disadvantage to the usability MANA was the 
inability to transfer created scenarios to other models. 
The TCP and UDP output streams were useful for combining 
simulation but did not allow analysis data to be collected 
in an effective way. In the Basic Scenario cargo 
measurement were made from multiple Excel spreadsheet 
entries taken from separate files across the multiple run 
output files. This was time consuming and not useful for 
quick and rapid analysis of key MOPs. 

3. Pythagoras 

Pythagoras was developed in conjunction with Project 
Albert in 2000 as previously discussed, in an attempt to 
model human factors in simulation environments. It 
introduced capabilities like soft decision rules for agents, 
dynamic "sidedness," alterations to behavior during run 
time, and nonlethal weapons (Bitinas, Henscheid, & Troung, 
2003). A design criterion for Pythagoras was the ability to 
run the simulation in batch mode for data farming. The 
usability of Pythagoras extended over platforms because of 
its JAVA based software. It was offered soft decision rules 
that were adjustable by the users to input variation in 
agent actions. The agent's processes did review their 
actions in a predetermined order, which allowed for some 
advantages and disadvantages to the agent interactions. 

Pythagoras was included in this research for comparison 
of multiple AABM. It has differences that are discussed in 
this section. Replications of the SBE scenario were not 
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needed for this model based on the similarity with MANA. 
Simulation results were predicted to match those of MANA. 
The SBE Scenario modeled was sufficient for comparison of 
the M&S capabilities in this research. 

a. Parameters 

The Pythagorus modeled scenario parameters are 
depicted in the following section. There were multiple 
attribute tabs that were used to set parameters for both the 
Basic and Advanced Scenarios. The tabs were Overview, 
Terrain, Weapon, "Sideness," Sensor, Comms, Agent, Attribute 
Changer, Alternate Behavior, and MOE. Figures 44 through 57 
show the SBE model basic model set up in the Pythagoras 
environment. 
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Comms Agent 

Attribute Changer 

Alternate Behavior MOE 


| Overview 

Terrain 

Weapon f Sidedness 

Sensor 

Scenario Properties 


Number Time Steps: 

1 500 | 

Random Seed 

m 

Random Index: 

m 


Overview Properties 


Scenario Description: 


PythagorasFiles 

SeaBasino Enabler Scenario 


This simulation will mocel the SBE operating in 
Non-Hostiie & Hostile environment 


Location: Sea of Japan 


Figure 18. 


Pythagoras Model 


Overview. 
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Position: | x=58Y-184~ | Time Step: 500 | Seed: 1 I | Index: I 1 I 



Figure 19. Pythagoras Map Overview. 


There were three unit instances used in the 
Pythagoras model. The first was the blue agent that 
represented T-craft. The blue agent force parameters 
settings are shown in Figures 44 through 48. The second 
instance was red agent forces that are found in Figures 49 
through 51. Shore, cargo, and MOE parameters are shown in 
Figures 52 through 57. These figures showed specific 

changes made to the default settings. A majority of the 
instance settings were similar for all units and remained 
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constant. Figure 20 lists the minor settings that were not 
shown in the basic model figures and remain constant. 



Basic Properties 


Terrain Dimension - 500 X 500 

Terrain Properties - Concealment = 0.0/Mobility = 1.0/Protection = 0.0 
Features Properties - Not Used 


Basic Properties 


Restoration Weapon - Default 
Weapon Targeted Against - Enemies 


PK Properties - Default Settings 


Default Settings 


Default Settings 


Default Settings 



Blue Agent 


Terrain Preference - Default Settings 
Weapon Possession - Not Used 
Engagement Desire - Default Settings 
Sensor Possession - Default Settings 
Comms Possession - Default Settings 
Side Property - Blue 
Attributes - Not Used 
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Resources 


Fuel/Resource Y/Resource Z - Not Used 
Triggers - Detect Friend 
End of Run MOE - Default Settings 

Red Agent 

Other Properties - Default Settings 

Terrain Preference - Default Settings 

Weapon Possession - Basic 

Engagement Desire - Default Settings 

Sensor Possession - Universal 

Comms Possession - Not Used 

Side Property - Red 

Attributes - Not Used 

Resources - Not Used 

Triggers - Not Used 

End of Run MOE - Default Settings 

Shore Agent 

Other Properties - Default Settings 
Terrain Preference - Default Settings 
Weapon Possession - Not Used 
Engagement Desire - Default Settings 
Sensor Possession - Default Settings 
Comms Possession - Default Settings 
Side Property - Blue 
Attributes - Not Used 
Resources 

Fuel/Resource Y/Resource Z - Not Used 
Triggers - Detect Friend 
End of Run MOE - Default Settings 


Figure 20. Pythagoras Model Parameters. 
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b. Differences in Pythagoras 

The differences between Pythagoras and MANA were 
not as dramatic as the differences between JCATS and 
Pythagoras. The first difference was the implementation of 
fuzzy logic or soft decision rules for agent actions. The 
concept of applied mathematics to decision making was used 
to better model the human factors as discussed above. The 
second difference was the representation of the battle space 
in Pythagoras, which lacked unit icons. This did not affect 
the simulation capabilities. 

The third difference was use of the DOS command 
line to run the simulation. This took away the usability of 
the simulation and forced uncommon program language on 
novice users. The fourth difference was outputted data 
format. Where MANA produces Transmission Control Protocol 
(TCP) and User Datagram Protocol (UDP) packets, Pythagoras 
used Extensible Markup Language to output data and scenario 
information. These methods both have their place in the M&S 
technology world and were accessible. 

The fifth difference was the addition of resources 
that enabled measurements of multiple elements in the model. 
The fuel representation in MANA limited it to a single 
measurement where Pythagoras expanded the idea of MOPs and 
MOEs. The sixth difference addressed the capability of 
Pythagoras to change entity "sideness" of an agent if 
altered in the simulation. This option was not engineered 
into MANA and provided a more robust ability to model 
scenarios other than conventional warfare directly that 
could impact SBE Scenarios. 
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c. 


Expected Results 


The SBE Scenario modeled in Pythagoras was not 
iterated for analysis purposes due to the amount of time 
needed for simulation iterations. It was also determined 
from single run iterations that the results obtained were 
similar to those of MANA and that multiple simulation 
replications were not required for evaluation the model. 
The limited number of simulations conducted showed similar 
survivability rates, transit times, and cargo transfers to 
those obtained in MANA. There were two additional results 
that were observed in Pythagoras that increased its 
scalability. The first was Battle Damage Assessment results 
that were recorded for simulation runs. The second was the 
recorded changes to agent attributes. 

C. NEXT-EVENT BASED 

Next-event or discrete event based models are based on 
the sequential events that happen within the simulation vice 
a given time interval. Next-event based models are 
notionally represented by event graphs that depict the 
elements, variables, and relationships of the simulation. 
The processing power of a next-event simulation is in the 
future event list and that no event can happen 
simultaneously with another. This makes DES more accurate 
than time-step based models. All models used have these 
basic elements and operate on these principles (Buss, 2002). 

1. Naval Simulation System 

NSS was developed by the Operations Analysis and 
Simulation Sciences (OASiS) Group of the Metron 

113 



Incorporation under Space and Naval Warfare Systems Command 
(SPAWAR) direction (PD-15) . NSS is a model that utilizes a 
classified database in most cases and is property of the 
U.S. Government. NSS has had limited testing for W&A due 
to lack of funding, however, contractor support and training 
is available upon reguest. NSS is an object orientated 
Monte Carlo M&S tool that provides up to theater level 
scenario application. It has been used in fleet exercises 
as well as war gaming to develop courses of actions for 
naval commands. NSS is designed to be use at the staff 
level (Metron, 2007). 

NSS's capability to model the full spectrum of 
maritime, joint, and combined military operations made it 
well suited for the SBE Scenario. Similar to MANA, T- 
craft's track was used to model the sea lanes of 
communication. There were two assumptions made in modeling 
the SBE Scenario in NSS: (1) Monte Carlo features were 
sufficient to have results matched to AABM that enabled for 
stochastic processes. Initial simulation iterations of the 
Advance Scenario revealed stochastic survivability results. 
This was determined to fit into the capability hierarchy. 
(2) Logistical support was assumed to be present. NSS had 
the capability of initializing logistical support to units. 
The scenarios were simulated without the use of logistical 
functions. Logistical options were not used to maintain 
consistency among models used. Figure 21 presents the Basic 
Scenario map viewed in the input editor. 
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Figure 21. NSS Map Overview. 

Analysis of the NSS simulation replications were not 
preformed on this model. There were multiple runs conducted 
on the Basic and Advanced Scenario for evaluation purposes 
due to time restriction. NSS has been an accredited M&S 
tool and extensively used by Commander Pacific Fleet, 
SPAWAR, naval air commands and operation offices. Scenario 
analysis in NSS was determined to not be needed, based on 
its accreditation. 

a. Parameters 

The NSS model was created through the use of five 
selection tabs in the input editor. The five tabs 
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controlled forces, C2 plans, ops plans, mission plans, and 
track/region editor. The unit instances were retrieved from 
the NSS database their actions were altered in accordance 
with the SBE Scenario. Unit instance settings for escort 
forces and T-craft are listed in Figures 58 through 61, and 
hostile forces are contained in Figures 62 through 66. 
Figures 67 through 68 list blue force parameters used in the 
Advanced Scenario. The Basic Scenario was modeled with same 
parameters as the Advanced Scenario with the exception of 
escort and hostile forces, where red forces are shown in 
Figures 61 and 65 through 66. There were controls like 
communication networks and warfare commander plans that 
attempted to persuade entity actions. The default settings 
were retained for sensor, signature, and weapons for unit 
instances. 

The commander warfare plans selection tabs are 
shown in Figures 69 and 70. These figures grouped the 
operational, C2, and mission settings in one figure to show 
the default settings for all controls. Blue and red force 
settings were identical and based on the instance generated 
from the NSS database. One variation from default settings 
was the all unit check box was selected in the 
communications tab to assist in scenario speed. The time 
duration of the SBE Scenario was entered as 9 hours to 
facilitate sufficient time for T-craft to complete a 
successful mission. The Advanced Scenario incorporated 
hostile air forces depicted as MIG 23s and SU-24s and 
introduced the design element used in the other M&S tools of 
hostile air threats. 
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b. Expected Results 


NSS was determined to yield two of the three MOPs 
based on limited runs performed. The MOE selection was 
limited to model defined parameters that were not flexible 
for SBE Scenarios. Transit time of T-craft was presented in 
the application of MOE to the scenario; survivability was 
selected as a second MOP to be recorded. The third MOP was 
not measurable in NSS due to the lack of functionality in 
entities to carry and transfer cargo. The MOP did not fit 
into the logistical support functionality. A functionality 
that was added to MOP selection that was not initially 
considered was the use of confidence intervals. This was 
integrated into the accuracy functionality under 
replication. 

2. Simkit 

Simkit was created at the NPS in 1996 by professor 
Arnold Buss and graduate student Kirk Stork to represent 
sensor oriented objects in a model and simulation 
environment to better model processes that provided 
alternatives to expense processes. The concept of discrete 
event simulation (DES) was centered on modeled abstract 
objects in a computer program that used event graph logic. 
Simkit was originally implemented in the Java computer 
language by Sun Microsystems. DES can widely be applied to 
other computer languages, but the Basic and Advanced 
Scenario were both written in Java based on the reusability 
of predefined object classes in the Simkit library at the 
NPS (Stork, 1996). The user interface was at the 
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Application Programmer Interface (API) level that required 
extensive modeling and use of the libraries (Buss, 2002) . 

The advantage of modeling abstract objects in DES was 
the use of the Listener Event Graph Objects (LEGO) component 
framework that enabled T-craft to be specifically modeled 
and not the scenario processes. Cargo transfer and 
logistical processes were modeled in extensive detail to 
account for all aspects of the SBE Scenario. This allowed 
for powerful modeling of the SBE Scenario processes, for 
example, all three MOPs were implemented and measured with 
more accuracy than time-step based models (Buss, 2002) . 
Simkit has a wide variety of uses and the NPS studies that 
have used Simkit included port usage, sonar process, and 
security issue models to show the versatility of the M&S 
tool. 

Deterministic and stochastic models depend on input 
parameters. The use of an API allowed for the use of random 
processes and slightly stochastic models to be generated for 
the SBE Scenarios. The reason for this was the pseudo 
random nature of the variant generation factory within 
Simkit. The advantage of using a Java based program was 
that a robust statistical analysis capability was available. 
The data analysis tools embedded in Simkit produced user 
defined analyzed results from multiple simulation runs at 
the end of run time. 

Figures 22 and 23 are the simple flow diagrams that 
represent the Basic and Advanced Scenario implemented with 
the Simkit API. The detailed event graphs for the Simkit 
model are shown in Figures 71 through 77. The detailed 
model illustrates the conditions and parameters used to 
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model the SBE Scenario. The model represented the 
interaction stations as states that indicated to the T-craft 
platform object what action to perform. MOPs were state 
variables that were linked to the platform objects and used 
property change functions to account for the change over a 
single iteration and not over the total number of 
replications. 



Figure 22. Event Graph for Basic Scenario. 

There were two assumptions used in the T-craft Mover 
Manager. The first assumption was that T-craft proceed back 
to debarkation point and not repaired once the mission was 
successful. The reality was that T-craft could stop for 
repairs at the SBO, but was not modeled to in Simkit. Time 
limitations did not allow for debugging and revision of the 
code. The second assumption was that T-craft departed the 
SBO with cargo greater than or equal to the minimum load 
requirement of the scenarios. This was defined in the 
parameters section and required for T-craft to transit to 
the shore landing site when cargo was needed for the mission 
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objective. Real-world application of T-craft could allow 
transit to the shore with any amount of cargo. 

In addition to the above assumptions there was a repair 
facility implemented in the Advanced Scenario. The repair 
facility was located in the SBO state in an attempt to model 
the SBO capability for repairs of T-craft during mission 
execution. An Arena model created by Mary McDonald, a 
research associate of the SEED center at the NPS, was the 
basis for evaluation of the Arena M&S tool used as the sixth 
model for evaluation. Other work included a SBE model that 
was created by Major Sebastian Scheibe from the Germany Army 
at the NPS. The purpose of the Scheibe model was to 
determine critical capabilities of T-craft listed in BAA 
(05-020). One major MOP that Major Scheibe concentrated on 
was survivability when a repair factor was introduced to an 
Arena model (Scheibe, 2010) . This was the basis for the 
added repair station in the Advanced Scenario. Figure 23 
shows the Advanced Scenario modeled in Simkit. 
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Figure 23. Event Graph for Advanced Scenario. 


a. Parameters 

There were two types of variables used in Simkit 
that were used as measurements in the scenario models. The 
first was a set of State variables that were defined as 
variables that change at least once during simulation. 
Table 13 lists the state variables used in the Basic and 
Advanced Scenario. The variables represented states and 
input parameters. 
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State Variables 

Label 

Definition 

Value 

c 

Cargo carried in T-craft (Tons) 

< 750 

D 

Damage taken by T-craft 

(0 - 1) 

s 

State Variable (Debarkation, SBO, Shore) 

2D Point 

X 

Survivability rate of T-craft 

(0 I 1) 

sc 

Shore landing site Cargo received (Tons) 

ST 

M 

Mission status Flag 

(0 I 1) 

t x 

Delay Time for transit time of T-craft 

Triangle (0, 90, 
180) 

t L 

Delay Time for loading time of T-craft 

Exp (X) 

t R 

Delay Time for repair time of T-craft 

Exp (X) 

tu 

Delay Time for unloading time of T-craft 

Exp (X) 

to 

Delay Time for detection time of hostile sensor 

Triangle (0, 10, 
20) 

tM 

Delay Time for movement time of unit 

Un (100, 1). 

tE 

Delay Time for End of Service 

waitDelay = 1.0 

t v 

Delay Time for Entering Range 

N (10, 1) 

tG 

Delay Time for Exit Range 

N (10, 1) 

U C 

Random amount of cargo loaded on to T-craft 

U ~ Un(0,750) 


Table 13. Simkit State Variables. 


The second type of variable is the set of 

Parameter variables. The Parameters variables represented 

constant values in scenario used to determine damage and 

cargo thresholds. Table 14 lists the Parameters used in the 

Basic and Advanced Scenario. The damage threshold (DT) was 

used to determine when entities reached critical points of 

sustained damage. The repair threshold (RT) indicated the 

need for repairs based on sustained damaged. Along with 

threshold settings, there were queues size parameters, which 

defined t-craft force levels, repair facilities, and shore 

landing sites. Shore landing site (SL), repair facility 

(R) , and loading stations (L) were set to one. The last 
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parameter used was a two dimensional point vector parameter 
that represented a geo-graphical location in the environment 
that was used for movement and modeled physics. 


Parameters 

Label 

Definition 

Value 

MinLD 

Minimum Load for T-craft (Tons) 

min = 300 

MaxLD 

Maximum Load for T-craft (Tons) 

max <= 750 

DT 

Damage threshold 

dt = 0.8 

RT 

Repair Threshold 

rt = 0.3 

CT 

Cargo Threshold 

ct = 750 

SL 

Number of shore landing sites 

1 

R 

Number of Repair Facilities 

1 

L 

Number of Loading Facilities 

1 

UL 

Number of Unloading Facilities 

1 

ST 

Shore landing site cargo threshold 

2000 

G 

Debarkation Point 

2D Point 

H 

SBO Point 

2D Point 

I 

Shore landing site Point 

2D Point 


Table 14. Simkit Parameters. 


The detailed Simkit model depicted the algorithm 
used for logic problem solving that made the T-craft model 
object change states and transfer cargo to the shore landing 
site. This was fundamentally different that AABM that used 
waypoints to direct motion and actions of agents. The DES 
relied heavily on user defined methods to guide the course 
of actions for the scenario. The methods used to create 
randomness in the simulation were distributions curves. 

There are three basic distributions that were used 
in Simkit. The first distribution was a Uniform (Un) that 
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provided random motion of hostile and escorts forces in the 


defined battle space of the SeaBase. Time-step model'’s 
random movement was arbitrarily to an image, where DES 
required correct physical interactions and placement. 
Uniform distributions were used to model the randomness of a 
ship's movement in the operation area (t M ) and for cargo 
load rates (u c ) . 

The second was a Triangle distribution that was 
based on the knowledge of limits to the distribution but no 
evidence recorded to validate. Given the transit time 
results from the MANA simulation, a rough gage of the time 


needed to 

transit 

the distance 

in 

the 

scenario was 

taken 

from Table 

13 to 

define transit 

(t x 

) , enter (t v ) , and 

exit 

range (t G ) 

times . 

The last 

was 

an 

Exponential 

(Exp) 

distribution that 

described rates 

of 

a process. 

The 


distribution selected for loading, unloading, and repair 
delays can be based on historical logistic mean times of 
completion. Generic place holders were used for the Simkit 
model. 


b. Design of Experiments 

The iteration of the Simkit model over a design 
space was based on the need to test the model prior to 
extensive simulation runs in the Simkit environment and to 
determine the number of runs needed that would produce 
sufficient trials for statistical results. Event graph 
models allowed for the user to hand simulate the model. 
This function was used to test the range of the model prior 
to replication. It also allowed for debugging of the 
algorithms prior to code generation. The idea behind the 


hand simulation was to test the model for all possible 
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states and situation T-craft transitioned to. Table 15 
shows the design of experiments for the hand simulation 
method. The two factors that were varied are cargo load 
outs and starting location. This also showed that three 
starting states were not possible in a SBE Scenario based on 
earlier assumptions. For example, the T-craft could not 
start from the SBO without cargo loaded; otherwise, the 
mission would be satisfied. The other starting states that 
were not possible were departing the shore landing site with 
cargo. The T-craft was designed to unload all cargo at the 
shore landings site. An important consideration in the 
verification of the model'’s predicted outcome was the use of 
non random delay times. Each hand simulation had similar 
even delay times that enabled low computational stress in 
carrying out the calculations. 
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Hand 

Simulation Design of 

Experiments 

Design 

Point 

Starting State 

Initial Cargo Load 

1 

Debarkation 

0 

2 

Debarkation 

300 

3 

Debarkation 

750 

4 

SBO 

0 

5 

SBO 

300 

6 

SBO 

750 

7 

SHO 

0 

8 

SHO 

300 

9 

SHO 

750 


Note: Not a possible starting state for a 

SBE Scenario. 


Table 15. Hand Simulation Design of Experiments. 


The second design question was determining the 
number of simulation runs required to obtain statistical 
significant results. The number of simulation iterations 
was set at 10,000 replications. Given the starting states 


in Table 15, 10,000 replications were conducted at each 

starting point to collect data on the three MOPs. 




c. Expected Results 

The expected results of the Simkit model were 
originally assumed to match the characteristics of the 
distributions chosen for the inputted values. The triangle 
distribution of the transit and detection delays coupled to 
the exponential rates of the loading states produced a mean 
that was translatable to real-world processes. This 
research was not directed at validating the results of 
Simkit but merely to evaluate obtained results. It did seem 
to be highly likely that the model, developed with actual 
data to model the SBE Scenario, increased its usability. 

d. Data Analysis 

The results of the hand simulation are listed in 
Table 16. The results did show the full range of expected 
outcomes needed to model the Advanced Scenario. The 
survivability rate of the T-craft indicated that further 
simulation in Simkit should provide sufficient results for 
analysis. The transit times and cargo delivered results of 
the hand simulation are also comparable to those of MANA. 
The hand simulation calculations are shown in Figures 78 
through 83. 
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Hand Simulation Results 

Initial State 

Initial Cargo 

Cargo 

Time 

Survivability 

Debarkati 

on 

0 

1060 

82 

X = 0 

Debarkati 

on 

300 

2260 

181 

X = 1 

Debarkati 

on 

750 

360 

62 

X = 0 

SBO 

0 




SBO 

300 

2030 

122 

X = 0 

SBO 

750 

2480 

126 

X = 1 

SHO 

0 

1060 

92 

X = 0 

SHO 

300 




SHO 

750 





Table 16. Hand Simulation Results. 


The results from the Simkit simulation of the SBE 
Scenario are listed in Table 17 through 19. The Basic 
Scenario illustrated the capability of statistical analysis 
of Simkit and measured the processes to enable optimization. 
The Simkit model in Appendix C represented the Advanced 
Scenario and was configured for measuring MOPs. The results 
showed that Simkit was affected by distributions in the 
modeling of T-craft in a pseudo stochastic environment. 
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Simkit Simulation Results 

Replications {100} 

Trips (1) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform [0, 750] 

450.79 ± 266.95 

54.0 

5.38 ± 2.92 

Normal [525, 200] 

440.11 + 283.91 

44.0 

5.76 ± 5.25 

Exponential [300] 

457.54 + 281.95 

52.0 

5.93 ± 4.31 


Replications 

Trips 

{1000} 

(1) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 

Rate 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

436.29 ± 266.25 

48.2 

5.83 ± 5.02 

Normal 

[525, 

. 200] 

440.09 ± 286.60 

49.6 

5.74 ± 4.68 

Exponential 

[300] 

433.43 ± 293.63 

49.2 

5.32 + 3.53 


Replications 

Trips 

{10000} 

(1) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 

Rate 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

435.31 + 271.69 

49.3 

5.51 ± 4.19 

Normal 

[525, 

. 200] 

441.33 ± 290.69 

49.3 

5.50 ± 4.03 

Exponential 

[300] 

441.33 ± 287.81 

49.6 

5.52 1 4.30 


Table 17. Simkit Results (One Trip to Shore). 


Simkit Simulation Results 

Replications {100} 

Trips (2) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform [0, 750] 

637.42 ± 475.05 

24.0 

6.10 ± 3.60 

Normal [525, 200] 

665.20 ± 486.42 

30.0 

6.50 ± 4.63 

Exponential [300] 

529.94 + 484.77 

36.0 

7.65 ± 6.31 


Replications 

Trips 

{1000} 

(2) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

702.31 ± 456.86 

30.9 

6.79 + 4.53 

Normal 

[525, 

. 200] 

703.11 ± 483.12 

30.4 

6.84 + 4.80 

Exponential 

[300] 

452.62 ± 405.61 

30.5 

6.72 + 4.35 


Replications 

Trips 

{10000} 

(2) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

702.54 ± 462.63 

31.2 

6.85 ± 4.74 

Normal 

[525, 

. 200] 

703.11 ± 483.12 

30.4 

6.84 ± 4.80 

Exponential 

[300] 

460.46 ± 405.61 

30.9 

6.73 ± 4.66 


Table 18. Simkit Results (Two Trips to Shore). 
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1 Simkit Simulation Results | 

Replications {100} 

Trips (3) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform [0, 750] 

676.28 ± 537.54 

14.0 

00 

+1 

00 

CM 

r- 

Normal [525, 200] 

706.21 ± 551.46 

17.0 

7.30 ± 4.67 

Exponential [300] 

549.19 ± 489.62 

19.0 

7.44 + 4.67 


Replications 

Trips 

{1000} 

(3) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

781.62 ± 498.04 

15.4 

7.82 ± 5.25 

Normal 

[525, 

. 200] 

776.14 ± 527.92 

14.3 

CD 

CD 

+ 1 

r- 

Exponential 

[300] 

521.23 ± 480.42 

19.2 

7.42 ± 4.95 1 


Replications 

Trips 

{10000} 

(3) 

Measures of Performance 

Distribution 

Parameters 

Shore Cargo 
Transferred (LT) 

Survivabillity 
Rate (%) 

Transit 

Times (sec) 

Uniform 

[0, 

750] 

744.37 + 518.41 

14.7 

7.44 ± 5.24 

Normal 

[525, 

. 200] 

752.62 ± 530.71 

14.4 

7.34 1 5.06 

Exponential 

[300] 

540.61 ± 484.60 

17.6 

7.44 ± 5.08 


Table 19. Simkit Results (Three Trips to Shore). 
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Simkit Raw Data (Exert) 

Number of Replications = 
Number of Trips = 1 
Uniform Distribution 
Parameters are [0,750] 

100 

Shore Cargo 

Survivability 

Time 

469.28 

1 

5.40 

0.00 

0 

1.26 

738.82 

1 

7.17 

381.89 

0 

5.66 

391.23 

1 

6.12 

441.07 

1 

9.42 

405.54 

0 

6.77 

740.65 

1 

6.88 

836.81 

1 

3.90 

511.24 

1 

9.07 

320.83 

1 

5.25 

621.89 

1 

5.08 

456.55 

1 

6.09 

561.93 

0 

19.78 

665.75 

1 

7.90 

0.00 

0 

2.56 

740.77 

1 

7.10 

575.28 

0 

8.81 

669.77 

0 

6.46 

970.78 

1 

7.30 

0.00 

0 

0.88 

703.29 

1 

6.37 

505.16 

1 

5.76 

713.77 

0 

8.25 

346.44 

1 

6.56 

605.55 

0 

5.37 

566.33 

0 

4.19 

835.02 

0 

4.03 

742.18 

1 

4.41 

0.00 

0 

0.69 

0.00 

0 

2.07 

640.07 

1 

3.68 

885.71 

1 

4.85 

352.59 

1 

7.98 

675.01 

1 

6.32 

0.00 

0 

1.56 

0.00 

0 

2.16 

359.51 

1 

7.30 

0.00 

0 

0.74 

586.05 

1 

8.72 


Table 20. Simkit Data Collection Excerpt. 
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Simkit results behaved similarly to those of MANA, 
in that when more trips to the shore were implemented, cargo 
transfer increased at the shore landing site. The confidence 
interval magnitudes from the Simkit simulation were larger, 
giving a wider range for the actual value to be in. This 
meant that the cargo transfer rates modeled within the 
simulations were subjective to the developer of the 
simulation and the modeler of T-craft and yielded results 
similar but not realistic to actual cargo transfer rates. 

3. Arena Simulation 

The Rockwell Automation Arena software M&S tool is 
primarily designed for business process applications. 
Arena's main versatility is based on converting flowchart 
process in a model that can be simulated for analysis. 
Arena was developed by the Rockwell Automation Technologies 
Incorporated in 2007. The Arena M&S tool is recommended for 
uses in (1) documenting, visualizing, and demonstrating 
processes with animation, (2) predicting system performance, 
(3) identifying system choke points, and (4) planning 
requirements. (RA, 2007) Arena is designed for use in the 
business environment and is less capable than Simkit for 
military operations. 

As mentioned earlier, the evaluation of the Arena M&S 

tool was based on a model created by Mary McDonald, a 

research associate of the NPS. The McDonald model 

implemented the second phase of the SBE Scenario where the 

scenario starts at the SBO and SBEs transit to and from the 

shore landings site transferring cargo. It was a basic 

model that focused on the cargo measurement and not 

survivability. An extrapolation in areas relating to the 
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MOPs of the McDonald model was the focus of this research. 
As with Pythagoras, simple testing was conducted with Arena 
to determine the presence of functionalities in the Arena 
model and evaluate the capabilities of the M&S tool. The 
Arena model was iterated over multiple runs to determine the 
transfer patterns and survivability rates similar to other 
M&S tools in this study. 

a. Parameters 

The McDonald model imported values from a database 
that runs the model. The database consisted of 14 
independent variables that are listed below. The model also 
created multiple T-craft objects for transferring cargo. 
The time delay was a random exponential distribution with 
the process containing 51 T-craft entities. T-craft 
entities conducted transfer of cargo in batches to the shore 
landing site and were then disposed of once a threshold of 
cargo was reached. The McDonald model replicated the 
process 512 times. The McDonald model did not implement the 
return transit to the debarkation point, but did input 
attack probabilities into the transit processes. Figure 24 
shows the McDonald model in Arena and illustrates the 
generation process of the entities from the database with a 
separate block for reading input from a designated file. 
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Figure 24. McDonald Arena Model Overview. 


The following is a listing of the variables that 
were parameter settings in the McDonald model. The database 
was divided into 14 different independent variables that 
were used to then calculate 12 dependent variables. The 
dependent variables were calculated outside the model and 
then used as input parameters for model simulation. 

• Cargo Payload Weight (Long Tons) 

• Cargo Deck Size (Square Feet) 

• Speed in Knots 

• Loading Time in hours 

• Unloading Time in hours 

• Number of T-craft 

• Number of Sea Spots for Loading 

• Refueling during Loading (Boolean Value) 

• Refueling Rates (Tons/hour) 

• Cargo Capacities (Long Tons) 

• Fuel Consumption while Loaded (Long Tons) 

• Fuel Consumption while Unloaded (Long Tons) 
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Batch Size 


• Number of Hits until Repair needed 

b. Differences in Arena 

The most notable difference in Arena from Simkit 
was the GUI that was available in Arena. However, the GUI 
presence did not overcome certain short comings that an 
object orientated M&S tool supports. Arena was able to 
display models graphically, but lacked the computational 
power. The lack of versatile variables and extensive random 
numbers separated Arena from the Simkit that has robust 
methods for stochastic processes. The results from an Arena 
model were simple and not as robust as the statistical 
calculation in the Simkit API. The Arena GUI was not open 
sourced and reduced user capability to model complex 
interactions with logic programming. These factors, coupled 
with limited combat modeling capabilities made Arena 
distinctively different. 

Arena and Simkit shared one similarity. The 
capability of waiting queues to be used for measuring 
logistics provided information in analysis on force factors 
and composition. Arena was specifically designed for 
business-like applications to optimize processes and 
determine the best combination of factors. Waiting queues 
were the basis for selecting both Simkit and Arena M&S tools 
in this research. 
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c. Expected Results 

The SBE Scenario modeled in the McDonald model was 
not iterated for analysis purposes in this study. Instead, 
the McDonald model was used as a comparison mechanism to 
evaluate Arena's simulation capabilities. It was apparent 
from initial simulation runs that the primary results 
obtained from provided databases were comparable with Simkit 
results. The determination was made that extensive 
simulation of the McDonald model, like that of MANA, would 
not be necessary due to time restriction and the clear 
presence of M&S capabilities. Limited simulations 
iterations conducted by Mary McDonald did show similar 
survivability rates, transit times, and cargo transfers 
compared to Simkit, which indicated the model was a viable 
SBE Scenario. Selection of MOPs were also similar to those 
of Simkit, therefore, high replications of Arena was not 
needed for evaluation purposes. 

M&S tools used in this study were selected base on 
capabilities to model a SBE and availability at NPS. The 
two types of models kept within the constructive realm of 
M&S. Each M&S tool possessed capabilities and limitations 
that made them differently suited for modeling a naval 
problem, but still usable to apply to the SBE Scenario 
broadly for measuring performance characteristics. The 
results collected in this chapter were too used to 
illustrate obtainable results and that each M&S tool 
evaluated by subjectively observed functionalities within 
the capability Hierarchy. 
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Figure 25. 


T-craft General 


Configuration. 



Figure 26. 


T-craft Personal Settings. 


137 




























































































Figure 27. 


T-craft Ranges 


Settings. 



Figure 2 8. 


T-craft Sensors 


Settings. 
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Figure 29. 


T-craft Algorithm 


Settings. 



Figure 30. 


Escort Personal 


Settings. 
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Figure 31. 


Escort Ranges 


Settings. 



Figure 32. 


Escort Sensors 


Settings. 
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Figure 33. 


Escort Weapons 


Settings. 



Figure 34. 


Hostile Personal Settings. 
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Figure 35. 


Hostile Ranges 


Settings. 



Figure 36. 


Hostile Sensors 


Settings. 
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Figure 37. 


Hostile Weapons 


Settings. 



Figure 38. 


Hostile Algorithm 


Settings. 
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Figure 39. 


Hostile Air Personal Settings. 



Figure 40. 


Hostile Air 


Ranges 


Settings. 
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Figure 41. 


Hostile Air 


Sensors 


Settings. 



Figure 42. 


Hostile Air 


Weapons 


Settings. 
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Figure 43. Hostile Air Algorithm Settings. 



□ Pythagoras: C:iThes»slPathegoruousntestPythSOJwCargoXtef .xml 


Figure 44. 


Blue Agent Position Property. 


146 


















































































□ Pythagoras: CnThestsiPat hegotuousf ilesiPyth SOJv/CargoXfer.xml 




O Pythagoras: C: ThesisPalhegoiuousFilesPyMSOJwCatgoXfer .xml 

Overview Terrain Weapon Sidedness Sensor Comms Agent Attnbuie cnanger Alternate Behavior MOE 


1 *” 1 

3lue 

Red 

Shore 


Delete 


Name: BHic Last Modified: 


DescnpOon: | | 



Figure 46. 


Blue Agent Speed Property. 
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0 Pythagoras: C:\Thesis'.PathegoruousFiles\PythSOJwCargoXfer.xml 

| Overview | Terrain | Weapon | Sidedness | Sensor j Comms Agent ] Attribute Changer | Alternate Behavior | MOE | 


Clone 

Delete 



Name: [Blue 

Last Modified: 

1 



Description: | 


Engagement Desire [ Sensor Possession | Comm Possession Side Property | Attributes | Resources 

Triggers | End of Run MOEs 

Position Property [ Other Properties | Speed Property | Movement Desire 

Terrain Preference | Weapon Possession 

Movement Method: Highest Desire ▼ 

Title 

%/Count/Force... 

%/Count/Force 

Desire 

Desire Tolerance 

Distance 

Distance Tolera. 


Toward The Leader If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From The Leader If Closer Than 



0.0 

0.0 

0.0 

0.0 

Toward Closest Unit Member If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Closest Unit Member If Closer T.. 



0.0 

0.0 

0.0 

0.0 

Toward Furthest Unit Member If Farther Than 



0.0 

0.0 

0.0 

0.0 

Toward Closest Friend If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Closest Friend If Closer Than 



0.0 

0.0 

0.0 

0.0 

Toward Furthest Friend If Farther Than 



0.0 

0 0 

0.0 

0.0 

Toward Injured Friend (Fraction Health) 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Toward Needing Fuel 



0.0 

0.0 

0.0 

0.0 

Toward Needing ResourceX 



50.0 

0.0 

100.0 

0.0 

Toward Needing ResourceY 



0.0 

0.0 

0.0 

0.0 

Toward Needing ResourceZ 



0.0 

0.0 

0.0 

0.0 

Toward Giving Fuel 



0.0 

0.0 

0.0 

0.0 

Toward Giving ResourceX 



50.0 

0.0 

50.0 

0.0 

Toward Giving ResourceY 



0.0 

0.0 

0.0 

0.0 

Toward Giving ResourceZ 



0.0 

0.0 

0.0 

0.0 

Toward Nearest Enemy If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Nearest Enemy If Closer Than 



0.0 

0.0 

15.0 

0.0 

Toward Nearest Enemy If Fewer Than Count 

0 

0 

0.0 

0.0 

0.0 

0.0 

Away From Nearest Enemy If More Than Co... 

1 

0 

0.0 

0.0 

15.0 

0.0 

Toward Nearest Enemy if Force Ratio More... 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Away From Nearest Enemy If Force Ratio L... 

1.5 

0.0 

0.0 

0.0 

0.0 

0.0 

Toward Next Waypoint 



80.0 

0.0 

5.0 

0.0 

Toward Final Objective 



15.0 

0.0 



Maintain Last Course 



0.0 

0.0 



Select Random Direction 



0.0 

0.0 



Stay in place 



0.0 

0.0 







Figure 47. 


Blue Agent Movement Desire. 
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□ Pythagoras: C:\TheslsiPathegoruousFaesPythSOJwCargoXrer junl 



f~1 Pythagoras: C:\TliestsPathsgoriiousF lies iPyth SO JwCai goXler junl 



Figure 49. 


Red Agent 


Position 


Property. 
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□ Pyrnaporas: cnTKeasPaincootuousfites'PymsoJwCafQoXIaf.xml 



Figure 50. 


Red Agent Speed Property. 
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EJ Pythagoras: C:\Thesis\Pathegoniou8rile8\PythSOJvvCargoXferjcml 
Overview Terrain Weapon Sidedness Sensor Comms Agent Attnbute Changer Alternate Behavior MOE 



Figure 51. 


Red Agent Movement Desire. 
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I ED Pyttnoras: C:iThesrsPamegotuousf*es'PythSOJwCatooXler-xml . 



. J Pythagoras: C:\ThesisPathegotuousFdesPythSOJwCargoXfer.xml 
Overview Terrain Weapon Sidedness Sensor Comms Agent Attribute Changer J Alternate Behavior MO€ 



Figure 53. 


Shore Agent Speed Property. 
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□ Pythagoras: C:iThesis\PalhegoruousF»es l ,PythSOJwCargoXlef.xml 


Overview Terrain Weapon Sided ness Sensor Comms Agent Attribute Changer Alternate Behavior HOE 



Description: | Landing site 

Engagement Desire Sensor Possession ! Comm Possession Side Property Attributes Resources Triggers ( EndolRunMOEs 

Position Properly Otner Properties Speed Property Movement Desire | Terrain Prolerence weapon Possession 


Movement Method: jlopTwo Desire w 

Title 

%/CountlForce 

WCountiForce 


Desire Tolerance 


Distance Tolera 


Toward The leader II Farther Than 



JO 

JO 

>0 

JO 

Away From The leader it Closer Than 



)0 

JO 

JO 

JO 

Toward Closest Unit Member it Farther Than 



)0 

JO 

J.O 

J.O 

Away From Closest Unit Member If Closer T 



)0 

JO 

JO 

J.O 

Toward Furthest Unit Member IIF3ither Than 



JO 

JO 

J.O 

JO 

Toward Closest Friend It Farther Than 



JO 

JO 

JO 

JO 

Away From Closest Friend it Closer Than 



JO 

JO 

JO 

JO 

Toward Fuithes! Friend If Failher Than 



JO 

JO 

J.O 

JO 

Toward injured Fnend (Fraction Health) 

JO 

>.0 

JO 

00 

JO 

JO 

Toward Heeding Fuel 



JO 

JO 

JO 

JO 

Toward Needing ResourceX 



>5.0 

JO 

J.O 

JO 

Toward Needing ResoutceY 



JO 

0.0 

J.O 

J.O 

Toward Needing Resource? 



JO 

JO 

JO 

JO 

Toward GMng Fuel 



JO 

>0 

J.O 

JO 

Toward Giving ResourceX 



95 0 

0.0 

1000 

JO 

Toward Giving ResourceY 



JO 

JO 

JO 

JO 

Toward Giving ResourceZ 



JO 

JO 

J.O 

JO 

Toward Nearest Enemy It Farther Than 



JO 

JO 

>0 

JO 

Away From Nearest Enemy it Closer Than 



JO 

JO 

J.O 

JO 

Toward Nearest Enemy IT Fewer Than Couni 

1 

J 

JO 

JO 

J.O 

J.O 

Away From Nearest Enemy It More Than Co 

3 

J 

JO 

JO 

J.O 

JO 

Toward Nearest Enem. if Force Ratio More 

JO 

J.O 

JO 

JO 

>0 

JO 

f 

I 

! 

i 

I 

Jf> 

5T5 

JO 

«l 

V6 

JO 

Toward Neil Waypoint 



JO 

JO 

J.O 

J.O 

Toward Final Objective 



JO 

00 



Maintain last Course 



JO 

JO 



Select Random Direction 



JO 

JO 







100.0 

20 






Figure 54. 


Shore Agent Movement Desire, 


G Pythagoras: C:.Thesis',Pathegoruousfiies PythSOJwCargoXfer.xml 



] Use Previous Behavior 


Average Speed: 1 Q Extend Sllderbar to 1000 

Q — . ■ 

0 10 20 30 40 50 60 70 80 90 100 

Average Speed Tolerance Factor 0 

O— . » 

0 10 20 30 40 50 60 70 80 90 100 

Variant in Speed Step to Step: 1 

Q— ^ . 

0 10 20 30 40 50 60 70 80 90 100 

Variant in Speed Step to Step Tolerance Factor 0 

Q 

0 10 20 30 40 50 60 70 80 90 100 


Figure 55. 


Cargo Alternate Behavior Speed Property. 
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2 Pythagoras C:\Thesis Pathegoruousflies PythSOJwf.argcXler.xml 
Overview Terrain Weapon Sidedness Sensor Com ms Agent Attribute Changer Alternate Behavior MOE 

Mew 
Clone 
Delete 


Name; Cargo Last Modified; 

Description: 

Weapon Possession Engagement Desire Sensor Possession j Comm Possession Side Property Attributes Resources j Triggers 

Posito n Property Other Properties Speed Property Movement Desire Terrain Preference 

□ Use Previous Behavior 


Movement Method: Average Desire ^ 


Title 

%;CDunt,Force 

VCountForce. 

Desire 

Desire Tolerance 

Distance 

Distance Tolera... 

Toward The Leader If FaitherThan 



0.0 

0.0 

0.0 

0.0 

Away Fiom The Leade If Closer Than 



0.0 

0.0 

0.0 

0.0 

Toward Closest Unit Member If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Closest Unit Member If Closer T 



0.0 

0.0 

0.0 

0.0 

Toward Furthest Unit Member II Farlher Thar 



0.0 

0.0 

0.0 

0.0 

Toward Closest Frienc If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Closest Friend If CloserThan 



0.0 

0.0 

0.0 

0.0 

Toward Furthest Friend If Farlher Than 



0.0 

0.0 

0.0 

0.0 

Toward Injured Friend (Fraction Health) 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Toward Needing Fuel 



0.0 

0.0 

0.0 

0.0 

Toward Needing Resourcex 



100.0 

ICO 

10.0 

5.0 

Toward Needing ResnnrceY 



00 

00 

loo 

00 

Toward Needing ResourceZ 



0.0 

0.0 

0.0 

0.0 

Toward Grvxig Fuel 



0.0 

0.0 

0.0 

0.0 

Toward Giving ResourceX 



oo 

00 

00 

00 

Toward Ghrino ResouroeY 



0.0 

0.0 

0.0 

0.0 

Toward Giving ResourceZ 



0.0 

0.0 

0.0 

0.0 

Toward Nearest Enemy If Farther Than 



0.0 

0.0 

0.0 

0.0 

Away From Nearest Enemy If Closer Than 



0.0 

0.0 

0.0 

0.0 

Toward Nearest Enemy If Fewer Than Count 

0 

0 

0.0 

0.0 

0.0 

0.0 

Away From Nearest Enemy If More Than Co. 

0 

0 

0.0 

0.0 

0.0 

0.0 

Toward Nearest Enemy if Force Ratio More ... 

0.0 

0.0 

0.0 

0.0 

loo 

0.0 

AwayFrom Nearest Eremy If Force Ratio L 

0.0 

0.0 

M 

0.0 

00 

0.0 

Toward Next Waypoint 



0.0 

0.0 

0.0 

0.0 

Toward Final Objective 



0.0 

0.0 



Maintain Last Course 



0.0 

0.0 



Select Random Direction 



0.0 

0.0 



Stay m oiace 



0.0 

0.0 




Alternative Behavior 
WfTIAL 

Cargo 


Figure 56. 


Cargo Alternate Behavior Movement Desire. 
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O Pythagoras: C:\ThesisiPattiegoniousFiles\PyUiSOJwCargoXfer.xfnl 



Figure 57. MOE for Model Iterations. 


Forces | C2 Plans | Ops Plans | Mission Plans | Track/Region Editor 

Commander Archive 

(Drag a commander to the command structure to add a commander instance): 

El Group Commanders 


Simple Force Commander 


& Simple Naval Commander 
- WMA Commanders 

♦ Air Warfare Commander 

♦ Anti-Submarine Warfare Commander 

♦ Land Warfare Commander 
^ Strike Warfare Commander 

♦ Surface Warfare Commander 


Figure 58. Blue Force and Warfare Commanders Structure. 
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Fnre* C2 Plans | rips Plans I Mission Plans | Trark/Reginn Frtitnr [ 

Aisel Archive 

(Drag an asset to the command stiuctme or map to add an asset instance): 


- uJ -acrlities 

♦ >CJ AAAs 
CJ Ait 8ases 

- Buidrngs 

4- Buldirg (Large) 

❖ GENERIC LAND BASE 
IB £j Others 
*• LJ SAMs 

- Cl Satellites 

- C3 Ships 

♦ Cj Amphibious Assaults 

♦ _J Amphibious T ranspoits 
» Cj Battle Cruisers 

*■ Cj BaHleshipj 

♦ Cj Cargos 
E CS Canieis 

© CHG Moskva 
© CV Admiral Kuznetsov 
© CV Clemenceau 
® CV Forrestal 
© CV Kitty Hawk 
© CV SaratcgalDmg 

□ CVH Kiev 

□ CVH Wasp 

□ CVHG Admiral Gorshkov 
© CVN Enterprise 

© CVN Nimilz 
© CVN Theodoie Roosevelt 

♦ CJ Coast Guards 

♦ CJ Combat Logislicss 

♦ CJ Command Ships 

♦ CJ Corvettes 

- Corsets 

LJ CG AcmiraIZozuya 

□ CGArtietam 

□ CG Belknap 
0 CG Kao 

□ CG Kreste II 
0 CG Kynda 

□ CG Leahy 

□ CG Pert Royal 
0 CG Slava 

0 CG Ticonderoga 
0 CGN Long Beach 185 
0 CGN Virginia 

- Destroyers 

□ D Suffren 

□ DC 1 Cassard 

0 DD ChienYang 
0 DD Dae Gu 
0 DD Ft Yang 
0 DD Georoes Leygues 




N 


Allance: | BLUE 

Command Structure: 


u 



Figure 59. Blue Unit Level Structure. 
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Forces 


C2 Plans | Ops Plans | Mission Plans | Track/Region Editor | 


T-crafl Systems 
Med-Resolution Sensoi List: 

Detection Type Detectable Targets Nominal Max Ra... Sensor Region Field... 

RADAR SURFACE, LAND,AIR, S... 15.7552 n/a n/a 


Sensor 
Skin Head 


Forces | C2 Plans | Ops Plans 

T -craft Systems 
Signature List: 

Signat ure 
Optical Vuln 
RADAR Vuln 
Infrared Vuln 
Passive acoustic Vuln 
Active acoustic Vuln 


Mission Plans | Track/Region Editor | 


Detection T ype 
OPTICAL 
RADAR 
INFRARED 
PASSIVE ACOUSTIC 
ACTIVE ACOUSTIC 


Alliance: | BLUE [▼] 


Command Structure: 


s 

AB 



♦ 

AZ 


□ 

FTZ 


& 

GW 


0 

JSM 


0 

IAS 



LS 


0 

T-crafl 

? 

Unassigned Forces 




Figure 60. 


T-craft Instance Settings. 


Forces | C2 Plans | Ops Plans | Mission Plans | Track/Region Editor | 


LAS Systems 

Med-Resolution Sensor List: 


Sensor 

Detection Type 

Detectable Targets 

Nominal Max Ra . Sensor Region 

Field 

AN/SPY-ID 

RADAR 

SURFACE. LAND. AIR. S 

188.3457 n/a 

n/a 

LowLight TV 

OPTICAL 

SURFACE. LAND. AIR 

8 9337 n/a 

n/a 

AN/SQS-53 

PASSIVE ACOUSTIC 

SUBSURFACE 

10 4000 n/a 

n/a 

AN/SSQ-104 

ELINT 

SURFACE. AIR 

535 4221 n/a 

n/a 

AN/SLQ-32(V)3(ESM BAND 1) 

EUNT 

SURFACE. AIR 

153.1351 n/a 

n/a 


Forces 


C2 Plans | Ops Plans | Mission Plans | Track/Region Editor | 


FTZ Systems 
Signature List: 


Signature Detection Type 

Optical Vuln OPTICAL 

RADAR Vuln RADAR 

Infrared Vuln INFRARED 

Passive acoustic Vuln PASSIVE ACOUSTIC 

Active acoustic Vuln ACTIVE ACOUSTIC 


Forces | C2 Plans | Ops Plans | Mission Plans | Tiack/Region Editor | 


Aliarrce: | BLUE 
Command Structure: 

B--0 AB 

♦ A2 

□ 

© GW 

□ JSM 

□ LAS 

♦ LS 

□ T-craft 

? Unassigned Forces 




FTZ Systems 
Weapon List: 


Weapon Systems 

Weapons 

Engageable Targets 

Max Range 

Loadout 

Mk41 VLS (1) 

RIM-66C Block III SM2MR 

AIR 

90.0000 

53 


RIM-66C Block II SM2MR 

AIR 

90.0000 

10 


RIM-66C Block 1 SM2MR 

AIR 

40 0000 

4 


BGM-109B Tomahawk TA 

SURFACE 

250 0000 

4 


BGM-109C TLAM BLOCK IIA 

LAND 

675 0000 

2 


BGM-109D TOMAHAWK 

LAND 

462 0000 

2 


RUR-139VL ASROC 

SUBSURFACE 

10 0000 

15 

Mkl 41 

RGM-84A Harpoon IA 

SURFACE 

65 0000 

8 

324mm Mk32SVTT Tnple 

Mk46 NEARTIP LWT 

SUBSURFACE 

6 0000 

18 


Mk50 Barracuda ALWT 

SUBSURFACE 

7 0000 

18 

127mm/54 Mk45 

127mm/54 AP 

LAND. AIR 

9 0000 

30 


127mm/54 HE 

LAND. AIR 

90000 

53 


127mm/54 HEAP 

SURFACE. LAND 

9.0000 

170 



Figure 61. 


Escort Instance Settings. 
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Forces 

C2 Plans 

Ops Plans 

Mission Plans 

Track/'Region Editor 

1 


Commander Archive 

(Drag a commander to the command structure to add a commander instance): 


Group Commanders 


□ Simple Force Commander 
& Simple Naval Commander 
- WMA Commanders 

♦ Air Warfare Commander 

♦ Anti-Submarine Warfare Commander 

♦ Land Warfare Commander 

♦ Strike Warfare Commander 

♦ Surface Warfare Commander 


Aiance: [RED 3 

Command Shurture: 


- Q RedFoice A8 

♦ Reduce AZ 
O RFA 
O RFB 
- O RFC 

* MG-238M Flogger H SQUADRON <04/25/101&32:27> [MIG-238M FLOGGER H] [2] 
^ $u-24MK Fencer D SQUADRON <02/19/10 08:29:44> [SU-24MK FENCER D] |3] 

7 Unas-signed Forces 


Figure 62. 


Red Force and Warfare Commanders Structure. 


Forces | C2 Plans | Ops Plans | Mission Flans | Track/Region Editor | 



Figure 63. 


Red Unit Level Structure. 
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Faces | C2Plans | Ops Plans | Mission Flans | Track/Region Edtor | 

Asset Aichive 


(Drag an asset to the command structure a map to add an asset nstarce) 


♦ _J Facihes 

• J SateAtes 
- "d Ships 

♦ _J Amphibious Assaults 

♦ LJ Amphibious Tianspats 

♦ _| Battle Gusas 

♦ _J Battleshps 

♦ Si Cargos 

♦ Sj Carnets 

♦ _J Coast Guards 

♦ □ Combat Logisbcss 

♦ □ Command Ships 

♦ Corvettes 

♦ 3 Cruisers 

- 'd| Destroyers 
0 DSuHren 
0 DDCassad 
0 DD Chen Yang 
0 DDDaeGu 
0 DDFuYang 
0 DD Georges Leygues 
0 DD Han Yang 
0 DDJecngBi* 

0 DDloYang 
□ DDLudal 

0 i»]iht;iii 
0 DD Spruance (VLS) 

0 DD Taejon 
0 DDTourvfe 
0 DDGAileigh Burke 
0 DDGBabi 
0 DDG Charles F Adams 
0 DDGFairagul 
0 DDG Kashin 
0 DDG Kashin Mod 
0 DDG Kidd 
0 DDGLuhu 
0 DDG Sovtemenny 
0 DDGUdaloy 
0 DDG Winston Church! 

3 Si Frigates 

♦ S| Hospitals 

♦ Landng Galls 

♦ _J Landng Shps 

♦ J Patrol Boats 

♦. Cl Tankas 

♦: Cl Subs 


Manee: (BED 3 

Command Structure 
- RedFotceAB 

♦ RerForceAZ 
O RFA 
O RFB 
B O RFC 

^ MG-238M Flogger H SQUADRON <04/25/101&32:27> [MIG-238M FLOGGER H] (2) 

Su-24MK Fencer D SQUADRON <02/19/10 08:29:44> [SU-24MK FENCER D] [3] 

? Unassigned Forces 


Figure 64. 


Red Unit Level Structure 


(cont.) 
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Forces ] C2 Plans | Ops Plans | Mission Plans | Track/Region Editor 


RFA Systems 

Med Resolution Sensoi List: 


Sensor 

Detection Type 

Detectable Targets 

Nominal MaxRa 

Sensor Region 

Field 

Rice Screen 

RADAR 

SURFACE, LAND, AIR, S... 

71.6143 

n/a 

n/a 

TAMIR 

PASSIVE ACOUSTIC 

SUBSURFACE 

11 0000 

n/a 

n/a 


Forces | C2 Plans | Ops Plans | Mission Plans | Track/Region Editor | 



RFA Systems 
Weapon List: 



Weapon Systems 

Weapons 

Engageable Targets 


HY-2 T nple 

HY-2 Silkworm 

SURFACE 


100mm/56 Single 

10Omm/56 Single DP 

AIR 

Forces 1 C2 Plans | 

Ops Plans | Mission Plans | Track/Region Editor | 

RFC Systems 

Signature List: 


Sgnature 

Detection Type 



Optical Vuln 

OPTICAL 



RADAR Vuln 

Infrared Vuln 

Passive acoustic Vuln 
Active acoustic Vuln 

RADAR 

INFRARED 

PASSIVE ACOUSTIC 
ACTIVE ACOUSTIC 



Figure 65. 

Hostile 


Max Range 
60 0000 
5.0000 


Loadout 

6 

30 


ASance ffiED 
Command Structure 


- RedFaceAB 

♦ RedFg cg AZ 

O 15^ I 

O RFB 
B 0 RFC 

MKJ-238M Flogger H SQUAOROM <04/25/10 1&3227> (MIG-238M FL0GGER H| |2| 
-«• Su-24MK Fenc« D SQUADRON <02/19/100ft2944> (SU-24MK FENCER 0| |3] 

? Unamgned Faces 




Forces | C2 Plans | Ops Plans | Mission Plans | Ttack/Region Editor | 


MiG 23BM Flogger H SQUADRON <04/25/10 18:32:27> Systems 
Med-Resolution Sensoi List: 


* 

*1 


Sensor 

Sirena-3 RWR 
Mk 1 Eyeball 


Detection Type 

ELINT 

OPTICAL 


Detectable Targets 
SURFACE, LAND. AIR 
SURFACE. LAND. AIR 


Nominal Max Ra... Sensoi Region Field 

27.5423 n/a n/a 

2 2334 n/a n/a 


Forces j C2 Plans | Ops Flans | Mission Plans | Track/Region Editor 

MiG 23BM Flogger H SQUADRON <04/25/10 18:32:27> Systems 
Signature List: 


Signature 
Optical Vuln 
RADAR Vuln 
Infrared Vuln 


Detection Type 
OPTICAL 
RADAR 
INFRARED 


Forces | C2 Plans | Ops Plans | Mission Plans | Ttack/Region Editor 


Alliance: flRED 3 

Command Sliuclure 


- ^ RedFotceAB 

♦ RedForce AZ 
O RFA 
O RFB 
B 0 RFC 


MG-238M Flogger H SQUADRON <04/25/1018:32:27> (MIG-238M FLOGGER H] [2] 


Su-24MK Fencer D SQUADRON <02/19/10 08:29:44> [SU-24MK FENCER D) [3] 
? Unassipned Foices 


* 

* 




MiG 23BM Floggei H SQUADRON <04/25/10 18:32:27> Systems 


Weapon List: 


Weapon Systems Weapons 

Engageable Targets 

Max Range 

MiG-238M Flogger H weapo... AS-7 Kerry 

SURFACE. LAND 

6.0000 

500kg Bomb 

SURFACE. LAND 

2 0000 

S-5K 57mm Rocket 

SURFACE. LAND 

20000 

AS-10 Karen 

SURFACE 

6.0000 



Figure 66. 


Hostile Force Instance Settings (cont.). 
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Forces C2 Plans | Ops Plans | Mission Plans | Track/Region Editor | 



Forces [ C2 Flans j Ops Plans | Mission Plans | Track/Region Editor | 

Warfare Commander Altribufes: 

AZ 


Asset C2 Options Summary: 


Asset 

| Start Time (dd:hh:mmss) | End Time (dd:hh:mm:ss) 

Sensor 

Weap 

| Motion | Max Engagements Max Sensor T« 

FTZ 

0 00:00:00 

9 00:00:00 

r 

r 

M 

GW 

0 00:00 00 

9 00 00 00 

ix 

[X 

lx 1 

JSM 

0 00:00:00 

9 00:00 00 

r 

r 

■: 

LAS 

0 00 00:00 

9 00 00 00 

r 

r 

» 

LS 

0 00:00:00 

9 00 00 00 

r 

r 

■i 

T -craft 

0 00:00:00 

9 00:00:00 

lx 

r 

ix 


Forces | C2 Plans Ops Plans j Mission Flans J t lack/ftegnn E dior | 

Moften j Commuracalom jj 

EMCON | 

Allured Conan i 

A2 

Command Cooler Allot 

GW 

Embarked Commanderi 

AB 

C2 Connoclrvrtjr: 

Uncomftanod 

Entry Paramelen 


Correspondent Hme/Cet Sgn 

1 Emfcarl.edCDRi 1 OutgonaMessepes ! Interring Messages 



Forces | C2 Plans | Ops Plans Mission Plans | Track/Regwn Ed*or | 
Mission Plan Templates 

(Drag a mission plan template to the Command Structure to add a new mission plan) 

' Air Warfare/! MD Plan 

Q Aircraft Alert Plan 
Q Antisubmarine Warfare Plan 
- €3 General Mission Plan 
0 Non-Recurring Plan 
Q Phased Plan 

Q Recurring Basic Aircraft Mission Plan 
□ TBM Salvo Plan 
D Intel.. Surv. & Recce Plan 
□ MCM SIN Plan 
0 MCM Sweep Plan 
0 Mine Laying Plan 
0 Strike Warfare Plan 
D Surface Warfare Plan 


Afcance: | BLUE 
Commend Structure 


t3AB 

& Aircraft Alert Plans 
♦ & General Mission Plans 
D Surface Warfare Plans 

□ FTZ 
© GW 

□ JSM 

□ LAS 


Figure 68. 


Blue Warfare Commander Settings. 
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Forces | C2 Plans Ops Plans | Mission Plans | Track/Region Editor | 
Motion | Communications | EMCON | 


C Stationary 


C Formation 


r 


(• Moving 


Complex Motion List: 


Motion 

Segment 

Type 

Specified Motion 

Use 

Default 

Duration 

Duration 

(hrs) 

Segment 

Operational 

State 

Segment Depth Profile 

IP 

<6 

T ransition 

Operational 

State 

Transition Depth Profile 

Time (hrs) 

Area 

REDFORCE AREA 


216.00 

PATROL 

NONE 

NA 

NA 

NA 

21600 


Forces | C2 Plans Ops Plans j Mtssion Plans | TrackyRegon Edtoi j 


Forces | C2 Plans OpsRans | Mission Plans | Track/Region Editor | 


Motion | 


Communications 


Motion Communications | EMCON | 


System Activation Schedules: RedFoteeAB 



5 


Percent Complete: 100% 


Connectivity Table: 



ALL ... 

RFA 

RFB 

RFC 

ALL RED 

X 




RFA 





RFB 





RFC 






Recipients 


Figure 69. 


Warfare Commander Settings (cont.). 


Fences C2 Plans j Ops Plans | Mission Plans j Track/Region Editor j 

Warfare Commander Attributes: 

RedForce AZ 


Asset C2 Options Summary: 


Asset 

| Start Time (dd:hh:mm:ss) 

End Time (dd:hh:mm:ss) 

Sensor 

Weap... 

Motion Max Engagements Max Sensor T* 

RFA 

0 00:00:00 

9 00 00 (W 

lx 

lx 

lx 1 

RFB 

0 00:00:00 

9 00:00:00 

lx 

lx 

lx 1 

RFC 

0 00:00:00 

9 00:00:00 

lx 

lx 

lx 1 


Forces | C2 Plans Ops Plans | Mission Plans | Track/Regx 
Motion I Communications || EMCON | 

Assuied Comms RedFoice AZ 

Command Centei Asset: RFA 

Embarked Commandeis: RedForceAB 


Entry Parameters: 


Alliance: (RED 

Command Structure: 




€3 RedFoteeAB 
♦ RedForce AZ 
O RFA 
O RFB 
S. O RFC 

Unassigned Forces 


Correspondent Name/Cat Sign | Embarked CORs 


RFB 

RFC 


I Outgoing Messages | Incommg Messages | 



Mission Plan Templates 
(Drag a mission plan template to the Command Structure to add a new mission plan): 

□ Air Wasfa<e/TMD Plan 

D Aircraft Alert Plan 

Antisubmarine Warfare Plan 
; General Mission Plan 
0 Non-Recurring Plan 
0 Phased Plan 
D Recurring Basic Aircraft 
□ TBM Salvo Plan 
Q Intel.. Suiv. & Recce Plan 

□ MCM SIN Plan 
D MCM Sweep Plan 
0 Mine Laying Plan 
Q Strike Warfare Plan 
Q Surface Warfare Plan 



Figure 70 


Red Warfare Commander Settings 
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Figure 72. T-craft Mover Manager Event Graph Object. 


Mediator 


Figure 73. Generic Referee Event Graph Object. 
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Figure 74 . 


Generic Mediator Event Graph Object. 
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Figure 76. Return to Base Event Graph Object. 
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Figure 77. Escort Random Mover Manager Event Graph 

Obj ect. 
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SimTime 

Event 

State (S) 

Cargo (S) 

Damage (D) 

Mission Flag (M) 

Shore Cargo (SC) 

[Next Event] 

0.00 

Run 

DBK 

0.00 

0.00 

0 

0.00 

[0, Load] 

0.00 

Load 

DBK 

0.00 

0.00 

0 

0.00 

[0, Transit] 

0.00 

Transit 

DBK 

0.00 

0.00 

0 

0.00 

[0, DBK to SBO] 

0.00 

DBK to SBO 

DBK 

0.00 

0.00 

0 

0.00 

[0, Start Move] 

0.00 

Start Move 

DBK 

0.00 

0.00 

0 

0.00 

[5, End Move; 1 Enter Range; 5 Exit Range] 

1.00 

Enter Range 

DBK 

0.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Detect] 

2.00 

Detect 

DBK 

0.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Attack] 

2.00 

Attack 

DBK 

0.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 BDA] 

2.00 

BDA 

DBK 

0.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range] 

5.00 

End Move 

DBK 

0.00 

0.00 

0 

0.00 

[5, State; 5 Exit Range] 

5.00 

State A 

SBO 

0.00 

0.00 

0 

0.00 

[5, Exit Range; 5 Load] 

5.00 

Load 

SBO 

360.00 

0.00 

0 

0.00 

[5, Exit Range; 15, Transit] 

5.00 

Exit Range 

SBO 

360.00 

0.00 

0 

0.00 

[5, Un-Detect; 15, Transit] 

5.00 

Un-Detect 

SBO 

360.00 

0.00 

0 

0.00 

[15, Transit] 

15.00 

Transit 

SBO 

360.00 

0.00 

0 

0.00 

[15, SBO to SHO] 

15.00 

SBO to SHO 

SBO 

360.00 

0.00 

0 

0.00 

[15, Start Move] 

15.00 

Start Move 

SBO 

360.00 

0.00 

0 

0.00 

[20, End Move; 20 .Exit Range; 16, Enter Range] 

16.00 

Enter Range 

SBO 

360.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, Detect] 

17.00 

Detect 

SBO 

360.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, Attack] 

17.00 

Attack 

SBO 

360.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, BDA] 

17.00 

BDA 

SBO 

360.00 

0.30 

0 

0.00 

[20, End Move; 20, Exit Range] 

20.00 

End Move 

SBO 

360.00 

0.30 

0 

0.00 

[20, State; 20, Exit Range] 

20.00 

Exit Range 

SBO 

360.00 

0.30 

0 

0.00 

[20, State; 20, Un-Detect] 

20.00 

Un-Detect 

SBO 

360.00 

0.30 

0 

0.00 

[20, State] 

20.00 

State A 

SHO 

360.00 

0.30 

0 

0.00 

[20, Unload] 

20.00 

Unload 

SHO 

0.00 

0.30 

0 

360.00 

[30, Transit] 

30.00 

Transit 

SHO 

0.00 

0.30 

0 

360.00 

[30, SHO to SBO] 

30.00 

SHO to SBO 

SHO 

0.00 

0.30 

0 

360.00 

[30, Start Move] 

30.00 

Start Move 

SHO 

0.00 

0.30 

0 

360.00 

[35, End Move; 35 Exit Range; 31 Enter Range] 

31.00 

Enter Range 

SHO 

0.00 

0.30 

0 

360.00 

[35, End Move; 35, Exit Range; 32, Detect] 

32.00 

Detect 

SHO 

0.00 

0.30 

0 

360.00 

[35, End Move; 35, Exit Range; 32, Attack] 

32.00 

Attack 

SHO 

0.00 

0.30 

0 

360.00 

[35, End Move; 35, Exit Range; 32, BDA] 

32.00 

BDA 

SHO 

0.00 

0.30 

0 

360.00 

[35, End Move; 35, Exit Range] 

35.00 

End Move 

SHO 

0.00 

0.30 

0 

360.00 

[35, State; 35, Exit Range] 

35.00 

State A 

SBO 

0.00 

0.30 

0 

360.00 

[35, Exit Range; 35, Repair] 

35.00 

Repair 

SBO 

0.00 

0.00 

0 

360.00 

[35, Exit Range; 55, Load] 

35.00 

Exit Range 

SBO 

0.00 

0.00 

0 

360.00 

[55, Load; 35 Un-Detect] 

35.00 

Un-Detect 

SBO 

0.00 

0.00 

0 

360.00 

[55, Load] 

55.00 

Load 

SBO 

700.00 

0.00 

0 

360.00 

[65, Transit] 

65.00 

Transit 

SBO 

700.00 

0.00 

0 

360.00 

[65, SBO to SHO] 

65.00 

SBO to SHO 

SBO 

700.00 

0.00 

0 

360.00 

[65, Start Move] 

65.00 

Start Move 

SBO 

700.00 

0.00 

0 

360.00 

[70, End Move; 70 .Exit Range; 66, Enter Range] 

66.00 

Enter Range 

SBO 

700.00 

0.00 

0 

360.00 

[70, End Move; 70, Exit Range; 67, Detect] 

67.00 

Detect 

SBO 

700.00 

0.00 

0 

360.00 

[70, End Move; 70, Exit Range; 67, Attack] 

67.00 

Attack 

SBO 

700.00 

0.00 

0 

360.00 

[70, End Move; 70, Exit Range; 67, BDA] 

67.00 

BDA 

SBO 

700.00 

0.12 

0 

360.00 

[70, End Move; 70, Exit Range] 

70.00 

End Move 

SBO 

700.00 

0.12 

0 

360.00 

[70, State; 70, Exit Range] 

70.00 

Exit Range 

SBO 

700.00 

0.12 

0 

360.00 

[70, State; 70, Un-Detect] 

70.00 

Un-Detect 

SBO 

700.00 

0.12 

0 

360.00 

[70, State] 

70.00 

State A 

SHO 

700.00 

0.12 

0 

360.00 

[70, Unload] 

70.00 

Unload 

SHO 

0.00 

0.12 

0 

1060.00 

[80, Transit] 

80.00 

Transit 

SHO 

0.00 

0.12 

0 

1060.00 

[80, SHO to SBO] 

80.00 

SHO to SBO 

SHO 

0.00 

0.12 

0 

1060.00 

[80, Start Move] 

80.00 

Start Move 

SHO 

0.00 

0.12 

0 

1060.00 

[85, End Move; 85 Exit Range; 81 Enter Range] 

81.00 

Enter Range 

SHO 

0.00 

0.12 

0 

1060.00 

[85, End Move; 85, Exit Range; 82, Detect] 

82.00 

Detect 

SHO 

0.00 

0.12 

0 

1060.00 

[85, End Move; 85, Exit Range; 82, Attack] 

82.00 

Attack 

SHO 

0.00 

0.12 

0 

1060.00 

[85, End Move; 85, Exit Range; 82, BDA] 

82.00 

BDA 

SHO 

0.00 


0 

1060.00 

[85, End Move; 85, Exit Range; 82, Killed] 

82.00 

Killed 

SHO 

0.00 


0 

1060.00 

[85, End Move; 85, Exit Range; 82, STOP] 

82.00 

STOP 

SHO 

0.00 


0 

1060.00 

o 

ii 

X 


MinLD 

300.00 


MaxLD 

750.00 


DT 

0.80 


RT 

0.30 


CT 

750.00 


SL 

1.00 


R 

1.00 


L 

1.00 


UL 

1.00 


ST 

2000.00 


G 

20.00 

20.00 

H 

0.00 

0.00 

I 

-30.00 

-30.00 

SPt 

20.00 

20.00 

EPt 

19.39 

196.23 


_10 

to 1 


u c 

0 

160 

400 

500 

350 

700 

120 

330 

750 

0 

0 

u c 

360 

700 

400 

500 

350 

700 

550 

330 

750 

300 

300 

d 

0 

0.3 

0.12 

0.9 

0.5 

0.44 

0.12 

0.21 

0.4 

0.88 

0.31 


Hand Simulation Design Point 1. 
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Figure 78 



























































































































SimTime Event State (S) Cargo (S) 

Damage (D) 

Mission Flag (M) Shore Cargo (SC) [Next Event] 

0.00 

Run 

DBK 

0.00 

0.00 

0 

0.00 

[0, Load] 

0.00 

Load 

DBK 

300.00 

0.00 

0 

0.00 

[0, Transit] 

0.00 

Transit 

DBK 

300.00 

0.00 

0 

0.00 

[0, DBK to SBO] 

0.00 

DBK to SBO 

DBK 

300.00 

0.00 

0 

0.00 

[0, Start Move] 

0.00 

Start Move 

DBK 

300.00 

0.00 

0 

0.00 

[5, End Move; 1 Enter Range; 5 Exit Range] 

1.00 

Enter Range 

DBK 

300.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Detect] 

2.00 

Detect 

DBK 

300.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Attack] 

2.00 

Attack 

DBK 

300.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 BDA] 

2.00 

BDA 

DBK 

300.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range] 

5.00 

End Move 

DBK 

300.00 

0.00 

0 

0.00 

[5, State; 5 Exit Range] 

5.00 

State A 

SBO 

300.00 

0.00 

0 

0.00 

[5, Exit Range; 5 Load] 

5.00 

Load 

SBO 

660.00 

0.00 

0 

0.00 

[5, Exit Range; 15, Transit] 

5.00 

Exit Range 

SBO 

660.00 

0.00 

0 

0.00 

[5, Un-Detect; 15, Transit] 

5.00 

Un-Detect 

SBO 

660.00 

0.00 

0 

0.00 

[15, Transit] 

15.00 

Transit 

SBO 

660.00 

0.00 

0 

0.00 

[15, SBO to SHO] 

15.00 

SBO to SHO 

SBO 

660.00 

0.00 

0 

0.00 

[15, Start Move] 

15.00 

Start Move 

SBO 

660.00 

0.00 

0 

0.00 

[20, End Move; 20 .Exit Range; 16, Enter Range] 

16.00 

Enter Range 

SBO 

660.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, Detect] 

17.00 

Detect 

SBO 

660.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, Attack] 

17.00 

Attack 

SBO 

660.00 

0.00 

0 

0.00 

[20, End Move; 20, Exit Range; 17, BDA] 

17.00 

BDA 

SBO 

660.00 

0.30 

0 

0.00 

[20, End Move; 20, Exit Range] 

20.00 

End Move 

SBO 

660.00 

0.30 

0 

0.00 

[20, State; 20, Exit Range] 

20.00 

Exit Range 

SBO 

660.00 

0.30 

0 

0.00 

[20, State; 20, Un-Detect] 

20.00 

Un-Detect 

SBO 

660.00 

0.30 

0 

0.00 

[20, State] 

20.00 

State A 

SHO 

660.00 

0.30 

0 

0.00 

[20, Unload] 

20.00 

Unload 

SHO 

0.00 

0.30 

0 

660.00 

[30, Transit] 

30.00 

Transit 

SHO 

0.00 

0.30 

0 

660.00 

[30, SHO to SBO] 

30.00 

SHO to SBO 

SHO 

0.00 

0.30 

0 

660.00 

[30, Start Move] 

30.00 

Start Move 

SHO 

0.00 

0.30 

0 

660.00 

[35, End Move; 35 Exit Range; 31 Enter Range] 

31.00 

Enter Range 

SHO 

0.00 

0.30 

0 

660.00 

[35, End Move; 35, Exit Range; 32, Detect] 

32.00 

Detect 

SHO 

0.00 

0.30 

0 

660.00 

[35, End Move; 35, Exit Range; 32, Attack] 

32.00 

Attack 

SHO 

0.00 

0.30 

0 

660.00 

[35, End Move; 35, Exit Range; 32, BDA] 

32.00 

BDA 

SHO 

0.00 

0.30 

0 

660.00 

[35, End Move; 35, Exit Range] 

35.00 

End Move 

SHO 

0.00 

0.30 

0 

660.00 

[35, State; 35, Exit Range] 

35.00 

State A 

SBO 

0.00 

0.30 

0 

660.00 

[35, Exit Range; 35, Repair] 

35.00 

Repair 

SBO 

0.00 

0.00 

0 

660.00 

[35, Exit Range; 55, Load] 

35.00 

Exit Range 

SBO 

0.00 

0.00 

0 

660.00 

[55, Load; 35 Un-Detect] 

35.00 

Un-Detect 

SBO 

0.00 

0.00 

0 

660.00 

[55, Load] 

55.00 

Load 

SBO 

700.00 

0.00 

0 

660.00 

[65, Transit] 

65.00 

Transit 

SBO 

700.00 

0.00 

0 

660.00 

[65, SBO to SHO] 

65.00 

SBO to SHO 

SBO 

700.00 

0.00 

0 

660.00 

[65, Start Move] 

65.00 

Start Move 

SBO 

700.00 

0.00 

0 

660.00 

[70, End Move; 70 .Exit Range; 66, Enter Range] 

66.00 

Enter Range 

SBO 

700.00 

0.00 

0 

660.00 

[70, End Move; 70, Exit Range; 67, Detect] 

67.00 

Detect 

SBO 

700.00 

0.00 

0 

660.00 

[70, End Move; 70, Exit Range; 67, Attack] 

67.00 

Attack 

SBO 

700.00 

0.00 

0 

660.00 

[70, End Move; 70, Exit Range; 67, BDA] 

67.00 

BDA 

SBO 

700.00 

0.12 

0 

660.00 

[70, End Move; 70, Exit Range] 

70.00 

End Move 

SBO 

700.00 

0.12 

0 

660.00 

[70, State; 70, Exit Range] 

70.00 

Exit Range 

SBO 

700.00 

0.12 

0 

660.00 

[70, State; 70, Un-Detect] 

70.00 

Un-Detect 

SBO 

700.00 

0.12 

0 

660.00 

[70, State] 

70.00 

State A 

SHO 

700.00 

0.12 

0 

660.00 

[70, Unload] 

70.00 

Unload 

SHO 

0.00 

0.12 

0 

1360.00 

[80, Transit] 

80.00 

Transit 

SHO 

0.00 

0.12 

0 

1360.00 

[80, SHO to SBO] 

80.00 

SHO to SBO 

SHO 

0.00 

0.12 

0 

1360.00 

[80, Start Move] 

80.00 

Start Move 

SHO 

0.00 

0.12 

0 

1360.00 

[85, End Move; 85 Exit Range; 81 Enter Range] 

81.00 

Enter Range 

SHO 

0.00 

0.12 

0 

1360.00 

[85, End Move; 85, Exit Range; 82, Detect] 

82.00 

Detect 

SHO 

0.00 

0.12 

0 

1360.00 

[85, End Move; 85, Exit Range; 82, Attack] 

82.00 

Attack 

SHO 

0.00 

0.12 

0 

1360.00 

[85, End Move; 85, Exit Range; 82, BDA] 

82.00 

BDA 

SHO 

0.00 

0.72 

0 

1360.00 

[85, End Move; 85, Exit Range; 82, Killed] 

85.00 

End Move 

SHO 

0.00 

0.72 

0 

1360.00 

[85, State; 85, Exit Range] 

85.00 

State A 

SBO 

0.00 

0.72 

0 

1360.00 

[85, Exit Range; 85, Repair] 

85.00 

Repair 

SBO 

0.00 

0.00 

0 

1360.00 

[85, Exit Range; 105, Load] 

85.00 

Exit Range 

SBO 

0.00 

0.00 

0 

1360.00 

[105, Load; 85 Un-Detect] 

85.00 

Un-Detect 

SBO 

0.00 

0.00 

0 

1360.00 

[105, Load] 

105.00 

Load 

SBO 

400.00 

0.00 

0 

1360.00 

[115, Transit] 

115.00 

T ransit 

SBO 

400.00 

0.00 

0 

1360.00 

[115,SBO to SHO] 

115.00 

SBO to SHO 

SBO 

400.00 

0.00 

0 

1360.00 

[115, Start Move] 

115.00 

Start Move 

SBO 

400.00 

0.00 

0 

1360.00 

[120, End Move; 120 .Exit Range; 116, Enter Range] 

116.00 

Enter Range 

SBO 

400.00 

0.00 

0 

1360.00 

[120, End Move; 120, Exit Range;117, Detect] 

117.00 

Detect 

SBO 

400.00 

0.00 

0 

1360.00 

[120, End Move; 120, Exit Range; 117, Attack] 

117.00 

Attack 

SBO 

400.00 

0.00 

0 

1360.00 

[120, End Move; 120, Exit Range; 117, BDA] 

117.00 

BDA 

SBO 

400.00 

0.32 

0 

1360.00 

[120, End Move; 120, Exit Range] 

120.00 

End Move 

SBO 

400.00 

0.32 

0 

1360.00 

[120, State; 120, Exit Range] 

120.00 

Exit Range 

SBO 

400.00 

0.32 

0 

1360.00 

[120, State; 120, Un-Detect] 
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Figure 79 




































































































































SimTime Event State (S) Cargo (S) 

Damage (D) 

Mission Flag (M) Shore Cargo (SC) [Next Event] 

0.00 

Run 

DBK 

0.00 

0.00 

0 

0.00 

[0, Load] 

0.00 

Load 

DBK 

750.00 

0.00 

0 

0.00 

[0, Transit] 

0.00 

T ransit 

DBK 

750.00 

0.00 

0 

0.00 

[0, DBK to SBO] 

0.00 

DBK to SBO 

DBK 

750.00 

0.00 

0 

0.00 

[0, Start Move] 

0.00 

Start Move 

DBK 

750.00 

0.00 

0 

0.00 

[5. End Move; 1 Enter Range; 5 Exit Range] 

1.00 

Enter Range 

DBK 

750.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Detect] 

2.00 

Detect 

DBK 

750.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 Attack] 

2.00 

Attack 

DBK 

750.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range; 2 BDA] 

2.00 

BDA 

DBK 

750.00 

0.00 

0 

0.00 

[5, End Move; 5 Exit Range] 

5.00 

End Move 

DBK 

750.00 

0.00 

0 

0.00 

[5, State; 5 Exit Range] 

5.00 

State A 

SBO 

750.00 

0.00 

0 

0.00 

[5, Exit Range; 5 Transit] 

5.00 

Exit Range 

SBO 

750.00 

0.00 

0 

0.00 

[5, Transit; 5, Un-Detect] 

5.00 

T ransit 

SBO 

750.00 

0.00 

0 

0.00 

[5, SBO to SHO] 

5.00 

SBO to SHO 

SBO 

750.00 

0.00 

0 

0.00 

[5, Start Move] 

5.00 

Start Move 

SBO 

750.00 

0.00 

0 

0.00 

[10, End Move; 10 .Exit Range; 6, Enter Range] 

6.00 

Enter Range 

SBO 

750.00 

0.00 

0 

0.00 

[10, End Move; 10, Exit Range; 7, Detect] 

7.00 

Detect 

SBO 

750.00 

0.00 

0 

0.00 

[10, End Move; 10, Exit Range; 7, Attack] 

7.00 

Attack 

SBO 

750.00 

0.00 

0 

0.00 

[10, End Move; 10, Exit Range; 17, BDA] 

7.00 

BDA 

SBO 

750.00 

0.30 

0 

0.00 

[10, End Move; 10, Exit Range] 

10.00 

End Move 

SBO 

750.00 

0.30 

0 

0.00 

[10, State; 10, Exit Range] 

10.00 

Exit Range 

SBO 

750.00 

0.30 

0 

0.00 

[10, State; 10, Un-Detect] 

10.00 

Un-Detect 

SBO 

750.00 

0.30 

0 

0.00 

[10, State] 

10.00 

State A 

SBO 

750.00 

0.30 

0 

0.00 

[10, Repair] 

10.00 

Repair 

SBO 

0.00 

0.00 

0 

0.00 

[30, Load] 

30.00 

Load 

SBO 

360.00 

0.00 

0 

0.00 

[30, Transit] 

30.00 

T ransit 

SBO 

360.00 

0.00 

0 

0.00 

[30, SBO to SHO] 

30.00 

SBO to SHO 

SBO 

360.00 

0.00 

0 

0.00 

[30, Start Move] 

30.00 

Start Move 

SBO 

360.00 

0.00 

0 

0.00 

[35, End Move; 35 .Exit Range; 31, Enter Range] 

31.00 

Enter Range 

SBO 

360.00 

0.00 

0 

0.00 

[35, End Move; 35, Exit Range; 32, Detect] 

32.00 

Detect 

SBO 

360.00 

0.00 

0 

0.00 

[35, End Move; 35, Exit Range; 32, Attack] 

32.00 

Attack 

SBO 

360.00 

0.00 

0 

0.00 

[35, End Move; 35, Exit Range; 32, BDA] 

32.00 

BDA 

SBO 

360.00 

0.12 

0 

0.00 

[35, End Move; 35, Exit Range] 

35.00 

End Move 

SBO 

360.00 

0.12 

0 

0.00 

[35, State; 35, Exit Range] 

35.00 

Exit Range 

SBO 

360.00 

0.12 

0 

0.00 

[35, State; 35, Un-Detect] 

35.00 

Un-Detect 

SBO 

360.00 

0.12 

0 

0.00 

[35, State] 

35.00 

State A 

SHO 

360.00 

0.12 

0 

0.00 

[35, Unload] 

35.00 

Unload 

SHO 

0.00 

0.12 

0 

360.00 

[45, Transit] 

45.00 

T ransit 

SHO 

0.00 

0.12 

0 

360.00 

[45, SHO to SBO] 

45.00 

SHO to SBO 

SHO 

0.00 

0.12 

0 

360.00 

[45, Start Move] 

45.00 

Start Move 

SHO 

0.00 

0.12 

0 

360.00 

[50, End Move; 50, Exit Range; 46, Enter Range] 

46.00 

Enter Range 

SHO 

0.00 

0.12 

0 

360.00 

[50, End Move; 50, Exit Range; 47, Detect] 

47.00 

Detect 

SHO 

0.00 

0.12 

0 

360.00 

[50, End Move; 50, Exit Range; 47, Attack] 

47.00 

Attack 

SHO 

0.00 

0.12 

0 

360.00 

[50, End Move; 50, Exit Range; 47, BDA] 

47.00 

BDA 

SHO 

0.00 

0.12 

0 

360.00 

[50, End Move; 50, Exit Range] 

50.00 

End Move 

SHO 

0.00 

0.12 

0 

360.00 

[50, State; 50, Exit Range] 

50.00 

State A 

SBO 

0.00 

0.12 

0 

360.00 

[50, Exit Range; 50, Load] 

50.00 

Exit Range 

SBO 

0.00 

0.12 

0 

360.00 

[50, Load, 50, Un-Detect] 

50.00 

Un-Detect 

SBO 

0.00 

0.12 

0 

360.00 

[50, Load] 

50.00 

Load 

SBO 

700.00 

0.12 

0 

360.00 

[60, Transit] 

60.00 

T ransit 

SBO 

700.00 

0.12 

0 

360.00 

[60, SBO to SHO] 

60.00 

SBO to SHO 

SBO 

700.00 

0.12 

0 

360.00 

[60, Start Move] 

60.00 

Start Move 

SBO 

700.00 

0.12 

0 

360.00 

[65, End Move; 65 .Exit Range; 61, Enter Range] 

61.00 

Enter Range 

SBO 

700.00 

0.12 

0 

360.00 

[65, End Move; 65, Exit Range; 62, Detect] 

62.00 

Detect 

SBO 

700.00 

0.12 

0 

360.00 

[65, End Move; 65, Exit Range; 62, Attack] 

62.00 

Attack 

SBO 

700.00 

0.12 

0 

360.00 

[65, End Move; 65, Exit Range; 62, BDA] 

62.00 

BDA 

SBO 


360.00 

[65, End Move; 65, Exit Range; 62, Killed] 

62.00 

Killed 

SBO 


360.00 

[65, End Move; 65, Exit Range; 65, Un-Detect; 62, STOP] 
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SimTime 

Event 

State (S) 

Cargo (S) 

Damage (D) 


0.00 

Run 

SBO 

0.00 

0.00 

0 

0.00 

[0, Load] 

0.00 

Load 

SBO 

300.00 

0.00 

0 

0.00 

[0, Transit] 

0.00 

Transit 

SBO 

300.00 

0.00 

0 

0.00 

[0, SBO to SHO] 

0.00 

SBO to SHO 

SBO 

300.00 

0.00 

0 

0.00 

[0, Start Move] 

0.00 

Start Move 

SBO 

300.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 1, Enter Range] 

1.00 

Enter Range 

SBO 

300.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, Detect] 

2.00 

Detect 

SBO 

300.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, Attack] 

2.00 

Attack 

SBO 

300.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, BDA] 

2.00 

BDA 

SBO 

300.00 

0.50 

0 

0.00 

[5, End Move; 5, Exit Range] 

5.00 

Exit Range 

SBO 

300.00 

0.50 

0 

0.00 

[5, End Move; 5, Un-Detect] 

5.00 

Un-Detect 

SBO 

300.00 

0.50 

0 

0.00 

[5, End Move] 

5.00 

End Move 

SBO 

300.00 

0.50 

0 

0.00 

[5, State] 

5.00 

State A 

SHO 

300.00 

0.50 

0 

0.00 

[5, Unload] 

5.00 

Unload 

SHO 

0.00 

0.50 

0 

300.00 

[15, Transit] 

15.00 

T ransit 

SHO 

0.00 

0.50 

0 

300.00 

[15, SHO to SBO] 

15.00 

SHO to SBO 

SHO 

0.00 

0.50 

0 

300.00 

[15, Start Move] 

15.00 

Start Move 

SHO 

0.00 

0.50 

0 

300.00 

[20, End Move; 20, Exit Range; 16, Enter Range] 

16.00 

Enter Range 

SHO 

0.00 

0.50 

0 

300.00 

[20, End Move; 20, Exit Range; 17, Detect] 

17.00 

Detect 

SHO 

0.00 

0.50 

0 

300.00 

[20, End Move; 20, Exit Range; 17, Attack] 

17.00 

Attack 

SHO 

0.00 

0.50 

0 

300.00 

[20, End Move; 20, Exit Range; 17, BDA] 

17.00 

BDA 

SHO 

0.00 

0.55 

0 

300.00 

[20, End Move; 20, Exit Range] 

20.00 

Exit Range 

SHO 

0.00 

0.55 

0 

300.00 

[20, End Move; 20, Un-Detect] 

20.00 

End Move 

SHO 

0.00 

0.55 

0 

300.00 

[20, State; 20, Un-Detect] 

20.00 

State A 

SBO 

0.00 

0.55 

0 

300.00 

[20, Repair] 

20.00 

Repair 

SBO 

0.00 

0.00 

0 

300.00 

[40, Load] 

40.00 

Load 

SBO 

550.00 

0.00 

0 

300.00 

[40, Transit] 

40.00 

Transit 

SBO 

550.00 

0.00 

0 

300.00 

[40, SBO to SHO] 

40.00 

SBO to SHO 

SBO 

550.00 

0.00 

0 

300.00 

[0, Start Move] 

40.00 

Start Move 

SBO 

550.00 

0.00 

0 

300.00 

[45, End Move; 45, Exit Range; 41, Enter Range] 

41.00 

Enter Range 

SBO 

550.00 

0.00 

0 

300.00 

[45, End Move; 45, Exit Range; 42, Detect] 

42.00 

Detect 

SBO 

550.00 

0.00 

0 

300.00 

[45, End Move; 45, Exit Range; 42, Attack] 

42.00 

Attack 

SBO 

550.00 

0.00 

0 

300.00 

[45, End Move; 45, Exit Range; 42, BDA] 

42.00 

BDA 

SBO 

550.00 

0.07 

0 

300.00 

[45, End Move; 45, Exit Range] 

45.00 

Exit Range 

SBO 

550.00 

0.07 

0 

300.00 

[45, End Move; 45, Un-Detect] 

45.00 

Un-Detect 

SBO 

550.00 

0.07 

0 

300.00 

[45, End Move] 

45.00 

End Move 

SBO 

550.00 

0.07 

0 

300.00 

[45, State] 

45.00 

State A 

SHO 

550.00 

0.07 

0 

300.00 

[45, Unload] 

45.00 

Unload 

SHO 

0.00 

0.07 

0 

850.00 

[45, Transit] 

45.00 

Transit 

SHO 

0.00 

0.07 

0 

850.00 

[45, SHO to SBO] 

45.00 

SHO to SBO 

SHO 

0.00 

0.07 

0 

850.00 

[45, Start Move] 

45.00 

Start Move 

SHO 

0.00 

0.07 

0 

850.00 

[50, End Move; 50, Exit Range; 46, Enter Range] 

46.00 

Enter Range 

SHO 

0.00 

0.07 

0 

850.00 

[50, End Move; 50, Exit Range; 47, Detect] 

47.00 

Detect 

SHO 

0.00 

0.07 

0 

850.00 

[50, End Move; 50, Exit Range; 47, Attack] 

47.00 

Attack 

SHO 

0.00 

0.07 

0 

850.00 

[50, End Move; 50, Exit Range; 47, BDA] 

47.00 

BDA 

SHO 

0.00 

0.12 

0 

850.00 

[50, End Move; 50, Exit Range] 

50.00 

Exit Range 

SHO 

0.00 

0.12 

0 

850.00 

[50, End Move; 50, Un-Detect] 

50.00 

Un-Detect 

SHO 

0.00 

0.12 

0 

850.00 

[50, End Move] 

50.00 

End Move 

SHO 

0.00 

0.12 

0 

850.00 

[50, State] 

50.00 

State A 

SBO 

0.00 

0.12 

0 

850.00 

[50, Load] 

50.00 

Load 

SBO 

680.00 

0.12 

0 

850.00 

[50, Transit] 

50.00 

Transit 

SBO 

680.00 

0.12 

0 

850.00 

[50, SBO to SHO] 

50.00 

SBO to SHO 

SBO 

680.00 

0.12 

0 

850.00 

[50, Start Move] 

50.00 

Start Move 

SBO 

680.00 

0.12 

0 

850.00 

[55, End Move; 55, Exit Range; 51, Enter Range] 

51.00 

Enter Range 

SBO 

680.00 

0.12 

0 

850.00 

[55, End Move; 55, Exit Range; 52, Detect] 

52.00 

Detect 

SBO 

680.00 

0.12 

0 

850.00 

[55, End Move; 55, Exit Range; 52, Attack] 

52.00 

Attack 

SBO 

680.00 

0.12 

0 

850.00 

[55, End Move; 55, Exit Range; 52, BDA] 

52.00 

BDA 

SBO 

680.00 

0.37 

0 

850.00 

[55, End Move; 55, Exit Range] 

55.00 

Exit Range 

SBO 

680.00 

0.37 

0 

850.00 

[55, End Move; 55, Un-Detect] 

55.00 

Un-Detect 

SBO 

680.00 

0.37 

0 

850.00 

[55, End Move] 

55.00 

End Move 

SBO 

680.00 

0.37 

0 

850.00 

[55, State] 

55.00 

State A 

SHO 

680.00 

0.37 

0 

850.00 

[55, Unload] 

55.00 

Unload 

SHO 

0.00 
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Figure 81. Hand Simulation Design Point 5. 


171 
































































































































SimTime 

Event State (S) Cargo (S) 

Damage (D) 

Mission Flag (M) Shore Cargo (SC) [Next Event] 

0.00 

Run 

SBO 

0.00 

0.00 

0 

0.00 

[0. Load] 

0.00 

Load 

SBO 

750.00 

0.00 

0 

0.00 

[0, Transit] 

0.00 

Transit 

SBO 

750.00 

0.00 

0 

0.00 

[0. SBO to SHO] 

0.00 

SBO to SHO 

SBO 

750.00 

0.00 

0 

0.00 

[0, Start Move] 

0.00 

Start Move 

SBO 

750.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 1, Enter Range] 

1.00 

Enter Range 

SBO 

750.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, Detect] 

2.00 

Detect 

SBO 

750.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, Attack] 

2.00 

Attack 

SBO 

750.00 

0.00 

0 

0.00 

[5, End Move; 5, Exit Range; 2, BDA] 

2.00 

BDA 

SBO 

750.00 

0.50 

0 

0.00 

[5, End Move; 5, Exit Range] 

5.00 

Exit Range 

SBO 

750.00 

0.50 

0 

0.00 

[5. End Move; 5, Un-Detect] 

5.00 

Un-Detect 

SBO 

750.00 

0.50 

0 

0.00 

[5, End Move] 

5.00 

End Move 

SBO 

750.00 

0.50 

0 

0.00 

[5. State] 

5.00 

State A 

SHO 

750.00 

0.50 

0 

0.00 

[5, Unload] 

5.00 

Unload 

SHO 

0.00 

0.50 

0 

750.00 

[15, Transit] 

15.00 

Transit 

SHO 

0.00 

0.50 

0 

750.00 

[15, SHO to SBO] 

15.00 

SHO to SBO 

SHO 

0.00 

0.50 

0 

750.00 

[15, Start Move] 

15.00 

Start Move 

SHO 

0.00 

0.50 

0 

750.00 

[20, End Move; 20, Exit Range; 16, Enter Range] 

16.00 

Enter Range 

SHO 

0.00 

0.50 

0 

750.00 

[20, End Move; 20, Exit Range; 17, Detect] 

17.00 

Detect 

SHO 

0.00 

0.50 

0 

750.00 

[20, End Move; 20, Exit Range; 17, Attack] 

17.00 

Attack 

SHO 

0.00 

0.50 

0 

750.00 

[20, End Move; 20, Exit Range; 17, BDA] 

17.00 

BDA 

SHO 

0.00 

0.55 

0 

750.00 

[20, End Move; 20, Exit Range] 

20.00 

Exit Range 

SHO 

0.00 

0.55 

0 

750.00 

[20, End Move; 20, Un-Detect] 

20.00 

End Move 

SHO 

0.00 

0.55 

0 

750.00 

[20, State; 20, Un-Detect] 

20.00 

State A 

SBO 

0.00 

0.55 

0 

750.00 

[20, Repair] 

20.00 

Repair 

SBO 

0.00 

0.00 

0 

750.00 

[40, Load] 

40.00 

Load 

SBO 

550.00 

0.00 

0 

750.00 

[40, Transit] 

40.00 

Transit 

SBO 

550.00 

0.00 

0 

750.00 

[40, SBO to SHO] 

40.00 

SBO to SHO 

SBO 

550.00 

0.00 

0 

750.00 

[0, Start Move] 

40.00 

Start Move 

SBO 

550.00 

0.00 

0 

750.00 

[45, End Move; 45, Exit Range; 41, Enter Range] 

41.00 

Enter Range 

SBO 

550.00 

0.00 

0 

750.00 

[45, End Move; 45, Exit Range; 42, Detect] 

42.00 

Detect 

SBO 

550.00 

0.00 

0 

750.00 

[45, End Move; 45, Exit Range; 42, Attack] 

42.00 

Attack 

SBO 

550.00 

0.00 

0 

750.00 

[45, End Move; 45, Exit Range; 42, BDA] 

42.00 

BDA 

SBO 

550.00 

0.07 

0 

750.00 

[45, End Move; 45, Exit Range] 

45.00 

Exit Range 

SBO 

550.00 

0.07 

0 

750.00 

[45, End Move; 45, Un-Detect] 

45.00 

Un-Detect 

SBO 

550.00 

0.07 

0 

750.00 

[45, End Move] 

45.00 

End Move 

SBO 

550.00 

0.07 

0 

750.00 

[45, State] 

45.00 

State A 

SHO 

550.00 

0.07 

0 

750.00 

[45, Unload] 

45.00 

Unload 

SHO 

0.00 

0.07 

0 

1300.00 

[45, Transit] 

45.00 

Transit 

SHO 

0.00 

0.07 

0 

1300.00 

[45, SHO to SBO] 

45.00 

SHO to SBO 

SHO 

0.00 

0.07 

0 

1300.00 

[45, Start Move] 

45.00 

Start Move 

SHO 

0.00 

0.07 

0 

1300.00 

[50, End Move; 50, Exit Range; 46, Enter Range] 

46.00 

Enter Range 

SHO 

0.00 

0.07 

0 

1300.00 

[50, End Move; 50, Exit Range; 47, Detect] 

47.00 

Detect 

SHO 

0.00 

0.07 

0 

1300.00 

[50, End Move; 50, Exit Range; 47, Attack] 

47.00 

Attack 

SHO 

0.00 

0.07 

0 

1300.00 

[50, End Move; 50, Exit Range; 47, BDA] 

47.00 

BDA 

SHO 

0.00 

0.12 

0 

1300.00 

[50, End Move; 50, Exit Range] 

50.00 

Exit Range 

SHO 

0.00 

0.12 

0 

1300.00 

[50, End Move; 50, Un-Detect] 

50.00 

Un-Detect 

SHO 

0.00 

0.12 

0 

1300.00 

[50, End Move] 

50.00 

End Move 

SHO 

0.00 

0.12 

0 

1300.00 

[50, State] 

50.00 

State A 

SBO 

0.00 

0.12 

0 

1300.00 

[50, Load] 

50.00 

Load 

SBO 

680.00 

0.12 

0 

1300.00 

[50, Transit] 

50.00 

Transit 

SBO 

680.00 

0.12 

0 

1300.00 

[50, SBO to SHO] 

50.00 

SBO to SHO 

SBO 

680.00 

0.12 

0 

1300.00 

[50, Start Move] 

50.00 

Start Move 

SBO 

680.00 

0.12 

0 

1300.00 

[55, End Move; 55, Exit Range; 51, Enter Range] 

51.00 

Enter Range 

SBO 

680.00 

0.12 

0 

1300.00 

[55, End Move; 55, Exit Range; 52, Detect] 

52.00 

Detect 

SBO 

680.00 

0.12 

0 

1300.00 

[55, End Move; 55, Exit Range; 52, Attack] 

52.00 

Attack 

SBO 

680.00 

0.12 

0 

1300.00 

[55, End Move; 55, Exit Range; 52, BDA] 

52.00 

BDA 

SBO 

680.00 

0.37 

0 

1300.00 

[55, End Move; 55, Exit Range] 

55.00 

Exit Range 

SBO 

680.00 

0.37 

0 

1300.00 

[55, End Move; 55, Un-Detect] 

55.00 

Un-Detect 

SBO 

680.00 

0.37 

0 

1300.00 

[55, End Move] 

55.00 

End Move 

SBO 

680.00 

0.37 

0 

1300.00 

[55, State] 

55.00 

State A 

SHO 

680.00 

0.37 

0 

1300.00 

[55, Unload] 

55.00 

Unload 

SHO 

0.00 

0.37 

0 

1980.00 

[65, Transit] 

65.00 

Transit 

SHO 

0.00 

0.37 

0 

1980.00 

[65, SHO to SBO] 

65.00 

SHO to SBO 

SHO 

0.00 

0.37 

0 

1980.00 

[65, Start Move] 

65.00 

Start Move 

SHO 

0.00 

0.37 

0 

1980.00 

[70, End Move; 70, Exit Range; 66, Enter Range] 

66.00 

Enter Range 

SHO 

0.00 

0.37 

0 

1980.00 

[70, End Move; 70, Exit Range; 67, Detect] 

67.00 

Detect 

SHO 

0.00 

0.37 

0 

1980.00 

[70, End Move; 70, Exit Range; 67, Attack] 

67.00 

Attack 

SHO 

0.00 

0.37 

0 

1980.00 

[70, End Move; 70, Exit Range; 67, BDA] 

67.00 

BDA 

SHO 

0.00 

0.77 

0 

1980.00 

[70, End Move; 70, Exit Range] 

70.00 

Exit Range 

SHO 

0.00 

0.77 

0 

1980.00 

[70, End Move; 70, Un-Detect] 

70.00 

Un-Detect 

SHO 

0.00 

0.77 

0 

1980.00 

[70, End Move] 

70.00 

End Move 

SHO 

0.00 

0.77 

0 

1980.00 

[70, State] 

70.00 

State A 

SBO 

0.00 

0.77 

0 

1980.00 

[70, Repair] 



Figure 82. Hand Simulation Design Point 6. 
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Figure 83. Hand Simulation Design Point 7. 
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VII. CAPABILITY EVALUATION 


A detailed capabilities hierarchy, described in Chapter 
IV, was developed to explore the abilities of selected M&S 
tools used at the NPS and in the DoD to model the potential 
SBE Scenario. Evaluation of those M&S tools, listed in 
Chapter VI, were the focus of the created functionality 
framework that was used for M&S modeling and implementation. 
The purpose of this chapter is to present results of the 
evaluation conducted on six M&S tools: JCATS, MANA, 
Pythagoras, NSS, Simkit, and Arena. The specific usability, 
flexibility, and scalability of the models were examined 
separately and then combined for a full comparison of the 
models across capabilities. Figures 84 through 101 show the 
complete evaluation of all M&S tools. 

Interpretation of the normalized factor in the 
evaluation of models was subjective based on the structure 
of the capabilities framework. A quartile approach was 
applied to associate a quick reference term with the 
determined value. Possible values for normalized factors 
range from zero to one, where threshold points for the 
quartiles were designated into four regions. Table 21 
indicates the threshold points and associated labels, where 
Very High represented a perfect contribution factor. 
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Quartil* 

5 Approach 

Value Range 

Associate Terms 

Definition 

0 to 0.25 

Low 

Contributes less than a quarter of 

the functionalities. 

0.26 to 0.50 

Medium 

Contributes less than half of the 

functionalities. 

0.51 to 0.75 

High 

Contributes greater than half of 

the functionalities. 

0.76 to 1.00 

Very High 

Contributes greater than three 

quarters of the functionalities. 


Table 21. Quartile Approach Listings. 

A. JCATS EVALUATION 

JCATS was evaluated with the use of the Jimenez model 
where Usability and Flexibility were High and Scalability 
was Medium. Table 22 shows the calculated values for JCATS 
capabilities. 


Joint Conflict and Tactical Simulation (JCATS) 


Capability 

Total 

Functionalities 

S (f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

38 

0.72 

0.64 

Flexibility 

49 

34 

0.69 

0.62 

Scalability 

42 

22 

0.52 

0.46 


Table 22. JCATS Capabilities Evaluation. 
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1. Advantages 


The first advantage of JCATS lied within the Dynamic 
situations that the M&S tool created with real-world values 
and physic representation. This functionality enabled 
direct translation of results; however, it also increased 
run times. Secondly, JCATS was one of two simulations 
evaluated that utilized securities by handling classified 
databases. Handling classified data was a key functionality 
DoD M&S tools possess. Lastly, JCATS was one of two 
simulations that were developed to be used in combination 
with other M&S tools for reusability, which allowed for the 
added benefit of architectural design to be observed. 

2. Disadvantages 

The first disadvantage of JCATS was implementation of 
real-world physics in the T-craft model during cargo 
transfer. T-craft's waypoints were modeled to allow for 
movement near the shore without landing, while remaining in 
sea mode. JCATS imposed shore landing conditions into the 
model and did not allow for T-craft to transit to the shore 
when the waypoints were placed on the shore line. Switching 
of modes from sea to hover consumed time during simulation 
and was not implemented in the Jimenez model. The second 
disadvantage was the lack of supportabilities provided to 
users. LT Jimenez had the benefit of hands on training with 
JCATS supported by the System Engineering program 
leadership. JCATS complexity did not lend itself to novice 
computer users like typical decision makers. 
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B. MANA EVALUATION 

MANA was evaluated with the implementation of the Basic 
and Advanced Scenarios in which all capabilities were rated 
as High. Table 23 shows the calculated values for MANA 
capabilities. 



Map Aware Non-Uniform Automata (MANA) 


Capability 

Total 

Functionalities 

2(f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

41 

0.77 

0.57 

Flexibility 

49 

37 

0.76 

0.55 

Scalability 

42 

35 

0.83 

0.61 


Table 23. MANA Capabilities Evaluation. 


1. Advantages 

The first advantage of MANA was the ease of 
implementation with MANA interface capabilities. The GUI 
applications in MANA enabled a working model to be ready for 
simulation runs without the need to debug code. The user 
was completely separated from the programming level. The 
second advantage was the numerous parameter settings 
available for manipulation of the model environment that 
include terrain map editor, agent attributes, and selectable 
complex behavioral actions. The overall capability of MANA 
was considered High. The third advantage was the AABM that 
facilitated the adjustability of agents with attributes and 
triggers. This enabled the user to define complex actions 
and decision processes that were not commonly found in M&S 
tools like DES. 


178 






2 . 


Disadvantages 


There were major disadvantages in MANA that would 
prevent its widespread use in DoD. The first was the lack 
of architectural design. MANA was not HLA compliant nor 
open sourced. The second disadvantage accompanied the 
first, where MANA did not conform to protocol standards or 
DoD standards in terminology and representation on the 
battle space. MANA's disadvantages were noticeable in its 
evaluations, nevertheless, most decision makers could work 
past these issues to use MANA and produce quality results. 

C. PYTHAGORAS EVALUATION 

Pythagoras evaluation yielded all capabilities as High. 
Table 24 shows the calculated values for Pythagoras 
capabilities. 


Capability 

Total 

Functionalities 

Pythagorus 

2(f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

37 

0.70 

0.56 

Flexibility 

49 

34 

0.69 

0.56 

Scalability 

42 

32 

0.76 

0.61 


Table 24. Pythagoras Capabilities Evaluation. 


1. Advantages 

The first advantage of Pythagoras was the robust 
selection of attributes and MOEs that greatly surpassed that 
of MANA. The MOEs were not available to be defined by the 
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user but were more capable in measuring parameters in the 
simulation than MANA recorded figures. The second advantage 
was the GUI that was implemented gave the user greater range 
of controls on agent actions. Weapons, sensors, and 
communication controls enabled the user to build elements of 
a model that accounted for significant amounts of 
probability. Pythagoras also introduced a "sideness" 
functionality that allowed for other entities to be created 
that were neutral, which added to dynamic situations. 

2. Disadvantages 

The first disadvantage of Pythagoras was that the large 
number of controls available to be adjusted by the user. 
The increased number of attributes, attitude changers, and 
movement desires often made the dynamics of the situation 
difficult to control without rigorous implementation plans. 
The second disadvantage was the lack of physics on entities. 
The bottom up approach of AABM did not seem to focus on real 
physics based models, but merely the behavior that modeled 
the individual entity actions. Pythagoras had the same 
disadvantages of MANA with reference to System architecture 
and interface functionalities, in which the observed 
capabilities contributions were High. 

D. NSS EVALUATION 

NSS was evaluated with the implementation of the Basic 
and Advanced Scenarios where all capabilities were High. 
Table 25 shows the calculated values for NSS capabilities. 


180 



Naval Simulation System (NSS) 


Capability 

Total 

Functionalities 

E(f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

34 

0.64 

0.55 

Flexibility 

49 

33 

0.67 

0.57 

Scalability 

42 

30 

0.71 

0.61 


Table 25 


NSS Capabilities Evaluation 


1. Advantages 

The first advantage of NSS was the use of real physics 
and environmental effects on entities during simulation like 
sea state and wind. NSS took input factors and applied 
physics forces during run time similar to JCATS. The second 
advantage was that the discrete-based processes allowed for 
more accurate results than time-step models. This was 
observed through the ability to select confidence interval 
values. The third advantage was NSS simulation run time 
durations were faster than those of JCATS in conducting 
multiple replication of the scenario. NSS simulation runs 
were conducted over hours, where JCATS were days in 
duration. The last advantage was that NSS allowed for near 
real time inputs to be fed into the model for course of 
action analysis. 

2. Disadvantages 

The first disadvantage of NSS was the inability of a 
DES to not model waiting queues to analysis processes in a 
model. The major advantage of the two following M&S tools 
was waiting queues for recorded MOPs. The second 


disadvantage was resource capabilities that did not allow 
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for cargo transfer to be measured. NSS was a federation 
program, but was not open source or HLA compliant in 
accordance with DoD mandates. The last disadvantage was the 
non access to probability tables of entities imported or 
copied from database instances. The ability to create a 
user defined entity was also not available. 

E. SIMKIT EVALUATION 

Simkit was evaluated with the implementation of the 
Basic and Advanced Scenarios where all capabilities were 
High. Table 26 shows the calculated values for Simkit 
capabilities. 


Capability 

Total 

Functionalities 

Simkit DES 

E(f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

25 

0.47 

0.64 

Flexibility 

49 

19 

0.39 

0.53 

Scalability 

42 

17 

0.40 

0.55 


Table 26. Simkit Capabilities Evaluation. 


1. Advantages 

The first advantage of Simkit was the discrete event 
processes that inherently provided highly accurate 
simulation results. The ability of the user to define 
virtually every aspect of the model interactions increased 
the Usability of Simkit with a 0.64 factor. The second was 
the technical support provided by the NPS in an academic 
setting that could be made available to decision makers. 
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The third was the freedom of programming to define 
parameters and output results that was not available in the 
other M&S tools. 

2. Disadvantages 

The first disadvantage of Simkit was the result data 
were highly dependent on the distributions used during 
simulations. The distributions were not limited by the 
Simkit API, only the ability of the user to create 
randomness for realistic interactions. The second 
disadvantage of Simkit was the lack of a GUI to implement 
models. This swing in capabilities between user interfaces 
made differences in the implementation of the SBE Scenarios 
but were leveled out in the evaluation processes. Simkit 
still offered High capabilities contributions. 

F. ARENA EVALUATION 

Arena was evaluated with the implementation of the 
Basic and Advanced Scenarios where the Usability capability 
was Very High and Flexibility and Scalability capabilities 
were Low. Table 27 shows the calculated values for Arena 
capabilities. 


Capability 

Total 

Functionalities 

Arena 

2(f) 

Roll up 
Probability 

Normalized (c) 

Usability 

53 

40 

0.75 

0.92 

Flexibility 

49 

10 

0.20 

0.25 

Scalability 

42 

10 

0.24 

0.29 


Table 27. Arena Capabilities Evaluation. 
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1. Advantages 


The first advantage of Arena was the GUI of a DES that 
provided Strong Usability of the M&S tool. This enabled 
MOPs to represent specific processes and obtain accurate 
results with confidence intervals. The second advantage was 
the ability of Arena to import and export databases for 
complex simulations. The McDonald model allowed for an 
implementation of a full factorial analysis to be conducted 
with varying parameters needed to determine relationships. 
The third advantage was the functionality of selectable 
units in the model that allowed for rapid MOP translations. 

2. Disadvantages 

The GUI of Arena was a highlight in its abilities due 
to the limitations of the M&S tool to model Military 
operations key to the Advanced Scenario. The first 
disadvantage was the lack of visual representation of a 
battle space in which the T-craft operated. The Arena 
processes were independent of location and based on a 
flowchart method. The second was the inability for entity 
interactions. Entity creation was limited to T-craft 
instances where escort and hostile forces could not be 
modeled. Similar to other M&S tool evaluated. Arena also 
was poorly designed for use in DoD with no HLA compliance or 
reusability. 

G. EVALUATION SUMMARY 

The evaluation of a capability hierarchy framework was 
an extensive compilation of six models created in six 
different M&S tools used in DoD and academia. The 


184 



evaluation summary is shown in Table 28 and compared M&S 
tools across capabilities. It was important to remember 
that all models were designed for a specific application of 
real situations and required validation in those areas. 


Capability 

JCATS 

Capability Hierarchy 

MANA Pythagorus 

Comparison 

NSS 

Simkit 

Arena 

Usability 

0.64 

0.57 

0.56 

0.55 

0.64 

0.92 

Flexibility 

0.62 

0.55 

0.56 

0.57 

0.53 

0.25 

Scalability 

0.46 

0.61 

0.61 

0.61 

0.55 

0.29 

Roll-up 

0.57 

0.58 

0.58 

0.58 

0.58 

0.49 


Table 28. Capabilities Evaluation Summary. 


The evaluation of the M&S tools showed similarities and 
differences in their capabilities. Comparison of the 
evaluations revealed that initial assessments of 
similarities between MANA and Pythagoras held true with High 
values in all capabilities. NSS was similar to MANA and 
Pythagoras despite being in different category types of M&S. 
The next major difference was found in the Arena evaluation 
where its Usability showed Very High values but Flexibility 
and Scalability had Low values. This was no surprise based 
on the limitations of the GUI based DES. Simkit and JCATS 
held similarities in Usability but differed in Scalability. 
JCATS and Arena Low values for Scalability both stemmed from 
the inability to allow for user access to attain abilities. 
Arena is the odd model with Low values for Flexibility and 
Scalability. Thus, the M&S user had multiple options that 
yielded high results. In the next chapter, a "suite of 
simulations" is suggested as a viable option. 
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Joint Conflict and Tactical Simulation (JCATS) 

Capability Evaluation 

Cap Charact Ility Trait Funct Functionality Element Pts Eval Total Remarks 

USABILITY SUM 0.72 

VALIDATION SUM 0.49 

CONSTRUCTABILITIES SUM 0.38 

DYNAMIC SITUATIONS SUM 0.25 

REPLIC. 

SUPPORTABILI1 

CONTRA' 

SENSOR PROB. TABLES 

1 

1 

0.02 

Actual Values 

WEAPON PROB. TABLES 

1 

1 

0.02 

Actual Values 

INDIVIDUAL UNIT ACTIONS 

1 

1 

0.02 

Limited 

AGENT INFORMATION (AI) 

1 

1 

0.02 

Limited 

AI - 

COURSE 

1 

1 

0.02 


AI - 

SPEED 

1 

1 

0.02 


AI - 

POSITIONAL DATA 

1 

1 

0.02 


AI - 

REFUELING RATES 

1 

1 

0.02 


AI - 

CARGO CAPACITIES 

1 

1 

0.02 


[COMMUNICATION (CM) 

1 

1 

0.02 

Information Exchange 

CM - 

COMMAND AND CONTROL ENTITY 

1 

0 

0.00 

Live SIM only 

CM - 

MILITARY OPERATIONS other than WARFARE 

1 

1 

0.02 

Ground Operations only 

CM - 

LOGISTIC CAPABILITIES 

1 

1 

0.02 


WAITING QUEUES 

1 

1 

0.02 

Supported DES 

PERSONAL SETTINGS 

1 

0 

0.00 


SEMI-AUTOMATED FORCES 

1 

0 

0.00 


ABLE SUM 0.13 | 

SIMULATE a user DEFINED MODEL 

1 

1 

0.02 


MULTIPLE RUNS DEFINED by user 

1 

1 

0.02 


MEASURES OF PERFORMANCE 

1 

1 

0.02 

Not User Defined 

PARAMETERS 

1 

1 

0.02 

Selectable 

RESET SIMULATION PARAMETERS 

1 

0 

0.00 


User DEFINED OUTPUT VARIABLES 

1 

1 

0.02 

Selectable 

START/STOP CRITERIA 

1 

1 

0.02 

Only Time 

ACCURACY 

1 

0 

0.00 


SPOT SAMPLING 

1 

1 

0.02 

Playback only 

’IES SUM 0.11 

CTOR SUPPORT SUM 0.09 

|BASIC INFORMAITON (BI) 

1 

1 

0.02 


BI - 

VERSION NUMBER 

1 

1 

0.02 


Bi - 

UPGRADE INFORMATION 

1 

1 

0.02 


REACH-BACK AVAILABILITY 

1 

0 

0.00 


POINTS OF CONTACTS (PC) 

1 

0 

0.00 


PC - |WEBSITE AVAILABILITY 

1 

0 

0.00 

No Active URL 

TRAINING and EDUCATION 

1 

1 

0.02 

Limited 

FEEDBACK LOOP 

1 

1 

0.02 


AUTHORITATIVE SOURCES 

1 

0 

0.00 


j DOCUMENTATION SUM 0.02 f 


FUNCTIONALITY TUTORIALS 

1 

0 

0.00 


HELP WINDOWS 

1 

0 

0.00 


User MANUAL 

1 

1 

0.02 

Fair 

PUBLICATIONS 

1 

0 

0.00 


ONLINE SUPPORT 

1 

0 

0.00 


User INTERFACE SUM 0.23 

Representabilities SUM 0.23 

Graphical User Interface (GUI) SUM 0.09 


|User input windows (UI) 

1 

1 

0.02 


UI - 

Pull Down Menus 

1 

1 

0.02 


UI - 

Check Boxes 

1 

1 

0.02 


UI - 

Typed in Values 

1 

1 

0.02 


UI - 

Adjustment sliders 

1 

1 

0.02 


|Set-up Wizards 

1 

0 

0.00 


j Comprehensive able SUM 0.13 I 


Pop-up Information 

1 

0 

0.00 


Common Terminology 

1 

1 

0.02 

Based on DoD Instructions 

User Feedback 

1 

1 

0.02 

Limited 

Help Menus 

1 

1 

0.02 


Standard Symbology (SM) 

1 

1 

0.02 

Based on DoD Instructions 

SM - 

Friendly, Hostile, & Neutral 

1 

1 

0.02 

Based on DoD Instructions 

Forces 


1 

1 

0.02 


|Object Templates 

1 

1 

0.02 



Figure 84. JCATS Usability Evaluation Sheet. 
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Joint Conflict and Tactical Simulation (JCATS) [ 



Capability Evaluation 





Cap Charact Ility 

Trait 

Funct 

Functionality Element 

Pts 

Eval 

Total 

Remarks 

Flexibility 




SUM 


0.69 


Modelable 




SUM 


0.53 


Securities 



SUM 


0.04 


j Classification 

SUM 


0.04 



Safeguard & Handle Classified Information 

1 

1 

0.02 

Government Certified 


Encryption / Decryption Devices 

1 

1 

0.02 


I Export 

/ Import abilities 

SUM 


0.06 


j Databases 


SUM 


0.06 



Systems (Created Models) 

1 

1 

0.02 



Environment (Terrian / Weather / etc.) 

1 

1 

0.02 



Imagary Data 

1 

0 

0.00 



Scenario Files 

1 

1 

0.02 


Adjust 

abilities 


SUM 


0.43 


j Systems 


SUM 


0.22 



|Multiple Attributes 

1 

1 

0.02 

Poor 


|Model : 

Basic Physics 

1 

1 

0.02 

Excellent 


Refueling Capabilities 

1 

1 

0.02 



Movement Parameters 

1 

1 

0.02 

Indirect Application 


Mode Selection 

1 

0 

0.00 



|Clone 

/ Copy Functions 

1 

1 

0.02 

Standard Copy 


|Military Operations (MO) 

1 

0 

0.00 



MO - 

Guard 

1 

0 

0.00 



MO - 

Patrol 

1 

0 

0.00 



MO - 

Orbit 

1 

0 

0.00 



MO - 

Attack 

1 

1 

0.02 

Standard 


MO - 

Flee / Run 

1 

1 

0.02 



MO - 

Grouping Functions 

1 

1 

0.02 

C2 Hierarchy 


MO - 

Inter Communications 

1 

0 

0.00 



MO - 

Remain in place 

1 

1 

0.02 



MO - 

Waypoint selection 

1 

1 

0.02 

Mandatory 


MO - 

Unit operations 

1 

1 

0.02 

C2 Hierarchy 

j Environment 


SUM 


0.14 



12D Terrain Modeling (2D) 

1 

1 

0.02 

Limited 


2D - 

Surface Configuration 

1 

1 

0.02 



2D - 

Natural Features 

1 

0 

0.00 



2D - 

Man-made Features 

1 

0 

0.00 



|Oceanographic Modeling (OM) 

1 

1 

0.02 

Limited 


|0M - | 

|Contours with depth data 

1 

1 

0.02 



|External Forces (EF) 

1 

1 

0.02 



EF - 

Wind 

1 

1 

0.02 



EF - 

Sea State 

1 

1 

0.02 


| Measures of Performance 

SUM 


0.04 



Survivability 

1 

1 

0.02 



Transit Times 

1 

1 

0.02 



| Cargo ' 

Transfer 

1 

0 

0.00 


| Resolution 


SUM 


0.02 



|T-craft Levels (Single vs. Multiple) 

1 i 

py 



J Architectural 

. Design 


SUM 


0.12 


J |Interoperability Standards & Protocol 

1 i 

|V:« 

I 0.02 

1 

| Federate Capable 


SUM 


0.06 



High Level Architecture (HLA) Capable 

1 

1 

0.02 



Reusable Program 

1 

1 

0.02 



Program History 

1 

1 

0.02 


Program Considerations 

SUM 


0.04 


[open - Source Code 

1 

0 

0.00 



Input 1 

Operational Data (10) 

1 

1 

0.02 

Operational User 


10 - | 

|0bject Library 

1 

1 

0.02 

Main Database 


|Auto Save / Auto Recover 

1 

0 

0.00 


Stochastic Process 



SUM 


0.04 


|Scriptable | | 

1 

1 

0.02 


| Discrete-Event 

1 

0 

0.00 



| Random 

Variables/Markov Principles 

1 

0 

0.00 


J |Time_Step 

1 

1 

1 

0.02 


_ 

| Random 

Variables/Markov Principles 

1 

0 

0.00 



Figure 85. JCATS Flexibility Evaluation Sheet. 
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1 Joint Conflict and Tactical Simulation (JCATS) f 


Capability Evaluation 





Cap Charact Ility Trait 

Funct 

Functionality Element 

Pts 

Eval 

Total 

Remarks 

Scalability 



SUM 


0.52 


Variation 



SUM 


0.52 


Adjust abilities 


SUM 


0.45 


Systems 


SUM 


0.26 



|Multiple Attributes 

1 

1 

0.02 

Poor 


|Model : 

Basic Physics 

1 

1 

0.02 

Excellent 


Refueling Capabilities 

1 

1 

0.02 



Movement Parameters 

1 

1 

0.02 

Indirect Application 


Mode Selection 

1 

0 

0.00 



|Clone 

/ Copy Functions 

1 

1 

0.02 

Standard Copy 


|Military Operations (MO) 

1 

0 

0.00 



MO - 

Guard 

1 

0 

0.00 



MO - 

Patrol 

1 

0 

0.00 



MO - 

Orbit 

1 

0 

0.00 



MO - 

Attack 

1 

1 

0.02 

Standard 


MO - 

Flee / Run 

1 

1 

0.02 



MO - 

Grouping Functions 

1 

1 

0.02 

C2 Hierarchy 


MO - 

Inter Communications 

1 

0 

0.00 



MO - 

Remain in place 

1 

1 

0.02 



MO - 

Waypoint selection 

1 

1 

0.02 

Mandatory 


MO - 

Unit operations 

1 

1 

0.02 

C2 Hierarchy 

j Environment 


SUM 


0.12 



12D Terrain Modeling (2D) 

1 

1 

0.02 

Limited 


2D - 

Surface Configuration 

1 

0 

0.00 



2D - 

Natural Features 

1 

0 

0.00 



2D - 

Man-made Features 

1 

0 

0.00 



|Oceanographic Modeling (OM) 

1 

0 

0.00 

Limited 


|0M - | 

|Contours with depth data 

1 

1 

0.02 



|External Forces (EF) 

1 

1 

0.02 



EF - 

Wind 

1 

1 

0.02 



EF - 

Sea State 

1 

1 

0.02 


J Measures of Performance 

SUM 


0.05 



Survivability 

1 

1 

0.02 



Transit Times 

1 

1 

0.02 



|Cargo ' 

Transfer 

1 

0 

0.00 


j Resolution 


SUM 


0.02 


j |T-craft Levels (Single vs. Multiple) 

1 i 

1 1 



Adjudication 



SUM 


0.07 


Attain 

abilities 

SUM 


0.07 



|Results (RS) 

1 

1 

0.02 

Limited 


RS - 

Units of Measure 

1 

0 

0.00 



RS - 

MOP's Translations 

1 

1 

0.02 

Indirect Application 


RS - 

User Defined Data Output 

1 

1 

0.02 



RS - 

Battle Damage Assessments 

1 

0 

0.00 



| Engagement (EG) 

1 

0 

0.00 



EG - 

Probability Tables Ph/Pk 

1 

0 

0.00 



EG - 

Sensor Algorithms Integration 

1 

0 

0.00 



EG - 

Weapons Algorithms Integration 

1 

0 

0.00 



EG - 

Indirect Fire Capabilities 

1 

0 

0.00 



EG - 

Sensor Detections 

1 

0 

0.00 



EG - 

Battle Damage 

1 

0 

0.00 



Figure 86. JCATS Scalability Evaluation Sheet. 
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Map Aware Non-Uniform Automata (MANA) 

Capability Evaluation 

Cap Charact Ility Trait Funct Functionality Element PtS Eval Total Remarks 

USABILITY SUM 0.77 

VALIDATION SUM 0.58 

CONSTRUCTABILITIES SUM 0.42 

DYNAMIC SITUATIONS SUM 0.26 

REPLIC. 

SUPPORTABILI1 

CONTRA' 

docume: 

User INTERFACE 

Representabil 
Graphi 

SENSOR PROB. TABLES 

1 

1 

0.02 


WEAPON PROB. TABLES 

1 

1 

0.02 


INDIVIDUAL UNIT ACTIONS 

1 

1 

0.02 


AGENT INFORMATION (AI) 

1 

1 

0.02 


AI - 

COURSE 

1 

1 

0.02 


AI - 

SPEED 

1 

1 

0.02 


AI - 

POSITIONAL DATA 

1 

1 

0.02 


AI - 

REFUELING RATES 

1 

1 

0.02 


AI - 

CARGO CAPACITIES 

1 

0 

0.00 


| C OMMUNICATION (CM) 

1 

1 

0.02 

Inter / Intra 

CM - 

COMMAND AND CONTROL ENTITY 

1 

1 

0.02 

C2 Hierarchy 

CM - 

MILITARY OPERATIONS other than WARFARE 

1 

1 

0.02 

Indirect Applications 

CM - 

LOGISTIC CAPABILITIES 

1 

1 

0.02 


WAITING QUEUES 

1 

0 

0.00 


PERSONAL SETTINGS 

1 

1 

0.02 

Excellent 

SEMI-AUTOMATED FORCES 

1 

1 

0.02 

Common Attributes 

ABLE SUM 0.15 f 

SIMULATE a user DEFINED MODEL 

1 

1 

0.02 


MULTIPLE RUNS DEFINED by user 

1 

1 

0.02 


MEASURES OF PERFORMANCE 

1 

1 

0.02 


PARAMETERS 

1 

1 

0.02 


RESET SIMULATION PARAMETERS 

1 

1 

0.02 


User DEFINED OUTPUT VARIABLES 

1 

0 

0.00 


START/STOP CRITERIA 

1 

1 

0.02 


ACCURACY 

1 

1 

0.02 


SPOT SAMPLING 

1 

1 

0.02 


'IES SUM 0.17 

CTOR SUPPORT SUM 0.13 

|BASIC INFORMAITON (BI) 

1 

1 

0.02 


BI - 

VERSION NUMBER 

1 

1 

0.02 

Versio 4.04.1 

Bi - 

UPGRADE INFORMATION 

1 

1 

0.02 


REACH-BACK AVAILABILITY 

1 

1 

0.02 

Limited 

POINTS OF CONTACTS (PC) 

1 

1 

0.02 

Email only 

PC - |WEBSITE AVAILABILITY 

1 

0 

0.00 


TRAINING and EDUCATION 

1 

1 

0.02 

Limited 

FEEDBACK LOOP 

1 

0 

0.00 


AUTHORITATIVE SOURCES 

1 

1 

0.02 

Project Albert 

NTATION SUM 0.04 | 

FUNCTIONALITY TUTORIALS 

1 

1 

0.02 

User Manual 

HELP WINDOWS 

1 

0 

0.00 


User MANUAL 

1 

1 

0.02 

Outdated 

PUBLICATIONS 

1 

0 

0.00 


ONLINE SUPPORT 

1 

0 

0.00 


SUM 0.19 

.ities SUM 0.19 

cal User Interface (GUI) SUM 0.09 

|User input windows (UI) 

1 

1 

0.02 


UI - 

Pull Down Menus 

1 

1 

0.02 


UI - 

Check Boxes 

1 

1 

0.02 


UI - 

Typed in Values 

1 

1 

0.02 


UI - 

Adjustment sliders 

1 

1 

0.02 


|Set-up Wizards 

1 

0 

0.00 


| Comprehensive able SUM 0.09 | 


Pop-up Information 

1 

1 

0.02 

Show Hints 

Common Terminology 

1 

0 

0.00 


User Feedback 

1 

1 

0.02 


Help Menus 

1 

0 

0.00 


Standard Symbology (SM) 

1 

0 

0.00 


SM - 

Friendly, Hostile, & Neutral 

1 

1 

0.02 

Selectable Icons 

Forces 


1 

1 

o 

o 

Transferable Scenario Files 

|object Templates 

1 

1 

| 0.02 | 

Transferable Scenario Files 


Figure 87. MANA Usability Evaluation Sheet. 
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Map Aware Non-Uniform Automata 

(MANA) 




Capability Evaluation 





Cap Charact Ility 

Trait 

Funct 

Functionality Element 

Pts 

Eval 

Total 

Remarks 

Flexibility 




SUM 


0.76 


Modelable 




SUM 


0.63 


Securities 



SUM 


0.00 


| Classification 

SUM 


0.00 



Safeguard & Handle Classified Information 

1 

0 

0.00 



Encryption / Decryption Devices 

1 

0 

0.00 


Export 

/ Import abilities 

SUM 


0.08 


| Databases 


SUM 


0.08 



Systems (Created Models) 

1 

1 

0.02 

Import Functions 


Environment (Terrian / Weather / etc.) 

1 

1 

0.02 

Limited 


Imagary Data 

1 

1 

0.02 

Bitmap Format 


Scenario Files 

1 

1 

0.02 

XML Format 

Adjust 

abilities 


SUM 


0.55 


1 Systems 


SUM 


0.33 



|Multiple Attributes 

1 

1 

0.02 

Good 


|Model : 

Basic Physics 

1 

0 

0.00 
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0.00 I 


12D Terrain Modeling (2D) 

1 

0 

0.00 



2D - 

Surface Configuration 

1 

0 

0.00 



2D - 

Natural Features 

1 

0 

0.00 



2D - 

Man-made Features 

1 

0 

0.00 



|Oceanographic Modeling (OM) 

1 

0 

0.00 



|OM - | 

|Contours with depth data 

1 

0 

0.00 



|External Forces (EF) 

1 

0 

0.00 



EF - 

Wind 

1 

0 

0.00 



EF - 

Sea State 

1 

0 

0.00 


| Measures of Performance 

SUM 


0.06 | 


Survivability 

1 

1 

0.02 

Excellent Processes 


Transit Times 

1 

1 

0.02 

Excellent Processes 


| Cargo ' 

Transfer 

1 

1 

0.02 

Excellent Processes 

| Resolution 


SUM 


0.00 | 


|T-craft Levels (Single vs. Multiple) 

1 i 

1 0 1 


Sinlge Entity Replicated 

1 Architectural 

. Design 


SUM 


0.04 

| |Interoperability Standards & Protocol 

1 i 

1 0 1 

| 0.00 I 

1 Federate Capable 


SUM 


0.00 


High Level Architecture (HLA) Capable 

1 

0 

0.00 



Reusable Program 

1 

0 

0.00 



Program History 

1 

0 

0.00 


Program Considerations 

SUM 


0.04 | 

|open Source Code 

1 

0 

0.00 



Input ' 

Operational Data (10) 

1 

1 

0.02 

Databases 


10 - | 

|0bject Library 

1 

1 

0.02 

Transferable Scenario Files 


|Auto Save / Auto Recover 

1 

0 

0.00 


Stochastic Process 



SUM 


0.06 | 

|Scriptable | | 

1 

1 

0.02 


| Discrete-Event 

1 

1 

0.02 



| Random 

Variables/Markov Principles 

1 

1 

0.02 

Distributions 

1 |Time_Step 

1 

1 

0 

0.00 


_^ 

| Random 

Variables/Markov Principles 

1 

0 

0.00 



Figure 100. Arena Flexibility Evaluation Sheet. 
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Arena 





Capability Evaluation 




Cap Charact Ility Trait 

Funct 

Functionality Element 

Pts 

Eval 

Total 

Remarks | 

Scalability 



SUM 


0.24 

Variation 



SUM 


0.24 

Adjust abilities 


SUM 


0.12 

Systems 


SUM 


0.02 


|Multiple Attributes 

1 

0 

0.00 



|Model : 

Basic Physics 

1 

0 

0.00 



Refueling Capabilities 

1 

1 

0.02 



Movement Parameters 

1 

0 

0.00 



Mode Selection 

1 

0 

0.00 



|Clone 

/ Copy Functions 

1 

0 

0.00 



|Military Operations (MO) 

1 

0 

0.00 



MO - 

Guard 

1 

0 

0.00 



MO - 

Patrol 

1 

0 

0.00 



MO - 

Orbit 

1 

0 

0.00 



MO - 

Attack 

1 

0 

0.00 



MO - 

Flee / Run 

1 

0 

0.00 



MO - 

Grouping Functions 

1 

0 

0.00 



MO - 

Inter Communications 

1 

0 

0.00 



MO - 

Remain in place 

1 

0 

0.00 



MO - 

Waypoint selection 

1 

0 

0.00 



MO - 

Unit operations 

1 

0 

0.00 


| Environment 


SUM 


0.00 | 


1 2D Terrain Modeling (2D) 

1 

0 

0.00 



2D - 

Surface Configuration 

1 

0 

0.00 



2D - 

Natural Features 

1 

0 

0.00 



2D - 

Man-made Features 

1 

0 

0.00 



|Oceanographic Modeling (OM) 

1 

0 

0.00 



|OM - | 

|Contours with depth data 

1 

0 

0.00 



|External Forces (EF) 

1 

0 

0.00 



EF - 

Wind 

1 

0 

0.00 



EF - 

Sea State 

1 

0 

0.00 


| Measures of Performance 

SUM 


0.07 t 


Survivability 

1 

1 

0.02 

Excellent Processes 


Transit Times 

1 

1 

0.02 

Excellent Processes 


|Cargo ' 

Transfer 

1 

1 

0.02 

Excellent Processes 

| Resolution 


SUM 


0.02 | 

| |T-craft Levels (Single vs. Multiple) 

1 i 

1 1 1 


| Sinlge Entity Replicated j 

Adjudication 



SUM 


0.12 

Attain 

abilities 

SUM 


0.12 


|Results (RS) 

1 

1 

0.02 



RS - 

Units of Measure 

1 

1 

0.02 

Time units 


RS - 

MOP's Translations 

1 

1 

0.02 



RS - 

User Defined Data Output 

1 

1 

0.02 



RS - 

Battle Damage Assessments 

1 

0 

0.00 



Engagement (EG) 

1 

0 

0.00 



EG - 

Probability Tables Ph/Pk 

1 

1 

0.02 

Imported Databases 


EG - 

Sensor Algorithms Integration 

1 

0 

0.00 



EG - 

Weapons Algorithms Integration 

1 

0 

0.00 



EG - 

Indirect Fire Capabilities 

1 

0 

0.00 



EG - 

Sensor Detections 

1 

0 

0.00 



EG - 

Battle Damage 

1 

0 

0.00 



Figure 101. Arena Scalability Evaluation Sheet. 
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VIII. 


SIMULATION COMPARISON 


Evaluation across M&S categories revealed similarities 
and differences among the M&S tools. These comparisons are 
generalized in this chapter to understand capabilities that 
were determined to be present. Select capabilities of the 
M&S tools used gave way to a combination of functionalities 
that may be used in future M&S development. The use of an 
M&S tool or a suite of M&S tools is introduced in this 
chapter for SBE modeling that could be expanded to other 
areas of research and development. A "suite of simulation" 
concept was discussed, due to the fact that the validation 
of a single M&S tool was, by definition, narrowed for a 
specific use. For example, what if a series of M&S tools 
linked or integrated together to utilize their complementary 
functionalities? The pros and cons of this idea are 
discussed. The last idea presented in this chapter is the 
trade space of M&S tools analyzed in this study and their 
limitations in a "suite of simulations." 

A. OBSERVED CAPABILITIES 

The two main types of simulations evaluated were time- 
step and next-event based models. These models displayed 
opposite strengths in capabilities of modeling a SBE 
Scenario. Time-step simulations scored High Scalability for 
scenario representation and attainability. The general 
functionalities displayed were agent actions and visual 
representation of the SBE Scenario. In models like MANA and 
Pythagoras, the ability of the user to define agent actions 
exceeded the actions of entities in next-event models. AABM 
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enabled controls for attained abilities that were 
specifically design to model the individual unit's decision 
making process remain an aspect of time-step based models. 
Next-event simulations scored High Usability for scenario 
validation and user interface. The functionalities derived 
from next-event based models were the implementation of 
physics based models and user interface options across M&S 
tools. Next-event based models'' key capabilities modeled 
real systems in simulation environments to test and measure 
performance in dynamic situations. The validation of the 
M&S tools was critical to the outcomes of simulation. 
Interface characteristics were observed in next-event 
models, in which the ability to model a wide range of 
processes showed High Usability contributions. 

There were associations within and across simulation 
types that were observed in the M&S tools used in this 
research. JCATS and NSS are both military-type simulations 
that modeled real physical entity interactions. 
Similarities of JCATS and NSS included (1) Environment 
representation that affected T-craft object motion and 
interactions, (2) Databases containing platform modeled 
objects that possessed real-world parameter inputs, (3) 
Federation of the M&S tools program to be reused and 
integrated with other source code, and (4) Securities to 
handle classified materials. Evaluation of MANA and 
Pythagoras capabilities revealed that there were similar GUI 
functionalities, which were attribute controls and 
replication abilities. 

Unexpectedly there was not the same level of 
correspondence between the next-event based models. NSS 


206 



differed from Simkit, which in turned differed from Arena. 
NSS and Arena shared similar functionalities like GUIs, yet 
showed differences in replication abilities and support 
systems. Simkit and Arena were both DES but differed in 
implementation of the interfaces. Simkit had High 
Flexibility and Scalability due to the MOP capabilities 
observed and optimized processes. Arena had Strong 
Usability with GUI, support functionalities, and replication 
applications. The three next-event models were as distinct 
as they were similar. 

B. SIMULATION SUITES 

The evaluation of the M&S tools in this research led to 
the guestion of which one or combination of simulations were 
capable of modeling a SBE Scenario. Combination of 
simulation was defined as a suite of integrated M&S tools. 
Beginning with the base model trade space, all possible 
"suites of simulations" would lie within the constructive 
model trade space as discussed in Chapter III. Based on the 
observed evaluation of the six models, the models with the 
highest Usability were Simkit and JCATS with 0.64, High 
contribution to the functionalities. Simkit'’s overall 
processes in Flexibility and Scalability were observed as 
High, which made an ideal candidate for SBE Scenario 
processing M&S tool. The models with a High Flexibility and 
Scalability were MANA and Pythagoras. These observed 
capabilities used in conjunction with DES surrounding the 
next-event based models as depicted in Figure 102, provided 
a possible solution trade space for SBE modeling. 
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Figure 102 illustrates the M&S space that a simulation 
or "suite of simulations" should be in for SBE Scenario 
modeling. The general idea behind the M&S trade space was 
to integrate the processing capabilities of DES with time- 
step based models to provide functionalities to flexible and 
scalable M&S tools. The limitation to this idea is the 
coupling of AABM with DES. Current AABM are not capable of 
introducing next-event based processes in the logic and/or 
source code. A possible "suite of simulations" is modeling 
cargo transfer processes in Simkit and transit interactions 
in MANA to solve for all MOPs. This would allow for the M&S 
space to encompass both types of simulations. 
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C. TRADE SPACE 

There are options being developed at the NPS to 
increase the capability of Simkit and DES. The Viskit 
simulation is an open source simulation code that attempts 
to marry the processing power of a DES with the usability of 
a GUI program. Viskit implements Java programming for use 
by non programmers. Viskit is a rapid development M&S tool 
that is based on reusable components of the Simkit API 
(Buss, 2008) . Viskit could be considered to provide the 
needed user interface that Simkit lacks. Arena can not be 
in the same discrete event space as Simkit because of the 
flowchart based model used. Arena is a next-event model but 
does not implement event graph properties that Simkit uses 
to create separate object entities. 

Based on Chapter VII results, there was another option 
in the trade space for a "suite of simulations" for SBE 
modeling. Simkit and NSS displayed similar capabilities in 
the evaluation. The possibility of NSS replacing Simkit in 
the "suite of simulation" space is worth exploring. NSS is 
a next-event based model with equivalent contributions to 
their capabilities. NSS additionally offers database 
functionality, in conjunction with the Simkit API may prove 
to be a powerful M&S tool. The trade space illustrates that 
the possibility for using M&S tools in series or tandem may 
provide decision makers with a product that has Very High 
capabilities for analysis and use. 
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IX. CONCLUSION 


The goal of the hierarchy framework was to define the 
M&S capabilities of a SeaBase Enabler (SBE) in a set of 
functionalities for evaluating simulations. The framework 
was generated to enable the application of a systematic 
process to be applied to any system to determine the 
capabilities and put a numeric value on the abilities 
relative to the total number of individual functionalities 
of the system. The results of the evaluations were then 
used to determine a suitable simulation or a "suite of 
simulations" for SBE modeling. 

There were six similar SBE models that were created in 
six different M&S tools. The six simple models merely 
provided a method for evaluating the capabilities of the 
simulations and to prove the framework was viable. Valuable 
insight was gained by scenario development of the basic 
models used. The intent of providing detailed modeling 
parameters was to enable future analysis in SBE modeling 
with models that are executable. 

The SBE concept is unique to military operations 
because of the potential logistical support by a transport 
craft that has not been offered in the past. The use of M&S 
in the development of a SBE like T-craft can provide insight 
into the advantages of large cargo capacities and increased 
speed capabilities. The scenarios created in this study 
were designed to specifically measure T-craft performance 
parameters and determine what could be modeled in the two 
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different types of simulation. The construction of a T- 
craft scenario in M&S tools allowed for comparison of 
capabilities across M&S Domains. 

All simulation types seem to have components that are 
interchangeable with each other. This integration can blur 
the distinctions between the two categories depicted here. 
However, use of specific simulations in this study, there 
were comparisons within and across the categories. The goal 
was to define the capabilities of a simulation for a SBE and 
provide a baseline for simulations that decision makers 
would want to conduct independent analysis to awareness. 
The battle over money for acquisition of systems has become 
overwhelming. Any assistance that can be provided by the 
ease of M&S tools will give options to DoD employees. 

The framework created has shown that an evaluation of 
simulations can be conducted. The bulk of the work 
conducted in this thesis was focused on the definition of 
the capability hierarchy. The initial assumption was that 
there would be an objective core to the framework to enable 
the measurement of capabilities for a given simulation. 
This was done by the presence or non presence of 
functionalities. Use of the roll-up method allowed for the 
contribution of any functionality to be calculated. 

The capability hierarchy was initially developed from 
the desired capabilities of a SBE but evolved with the 
research to incorporate other M&S requirements. End users' 
(Stakeholders) needs were the driving force behind the list 
of capabilities for a SBE. Based on the combination of end 
user needs and DoD capability requirements for M&S tools, 
the creation of the capability hierarchy allowed for a wide 
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range of operations to be modeled in a SBO Scenario. Model 
development seems to have led to additions in all areas of 
capabilities. The process of creating a framework for other 
systems may take extensive exploration in the solution trade 
space. 

Finally, this framework demonstrated that objective 
comparison of simulations capabilities that could be made 
with what first seems to be a subjective approach. The 
question of how capable is a simulation at first glance, is 
not objective. This thesis attempted to objectively show 
that with the use of a roll-up method, an subjective or 
quantitative comparison could be made of individual M&S 
tools, along with comparison across multiple simulations 
category types. The end results of the comparison showed 
that a "suite of simulations" could be more capable of 
modeling a SBE Scenario than a single simulation, but shows 
that specific individual simulations have been created with 
a combination of the more capable elements of the M&S tools 
evaluated. 
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APPENDIX A. CAPABILITY HIERARCHY 


Usability 


Validation 

Construct abilities 
Dynamic Situations 

Sensor Probability Tables 
Weapons Probability Tables 
Individual Unit actions 
Agent Information 
-Course 
-Speed 

-Positional Data 
-Refueling Rates 
-Cargo Capacities 
Communications 

-Command and Control Entity 
-Operation other than Warfare 
-Logistic Capabilities 
Waiting Queues 
Personal Settings 
Semi-Automated Forces 
Replicable 

Simulate a user defined model 
Multiple Runs defined by user 
Measure of Performance 
Parameters 

Reset Simulation Parameters 
User Define output variables 
Start/Stop Criteria 
Accuracy 
Spot Sampling 
Support abilities 
Contractor Support 
Basic Information 
-Version Number 
-Upgrade information 
Reach-back Availability 
Points of Contact 
-Web Site Availability 
Training & Education 
Feedback Loop 
Authoritative Sources 
Documentation 

Functionality Tutorials 
Help Windows 
User Manual 
Publications 
On-line Support 
User Interface 
Represent abilities 
Graphical User Interface (GUI) 
User input windows 


215 



-Pull Down Menus 
-Check Boxes 
-Typed in Values 
-Adjustment sliders 
Set-up Wizards 
Comprehensive able 
Pop-up Information 
Common Terminology 
User Feedback 
Help Menus 
Standard Symbology 
-Friendly, Hostile, & Neutral 
Forces 

Object Templates 
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Flexibility 


Model able 
Securities 
Classification 

Safeguard & Handle Classified 
Information 

Encryption / Decryption Devices 
Export / Import abilities 
Databases 

Systems (Created Models) 

Environment (Terrain / Weather / etc.) 
Imagery Data 
Scenario Files 
Adjust abilities 
Systems 

Multiple Attributes 
Model Basic Physics 
Refueling Capabilities 
Movement Parameters 
Mode Selection 
Clone / Copy Functions 
Military Operations 
-Guard 
-Patrol 
-Orbit 
-Attack 
-Flee / Run 
-Grouping Functions 
-Inter Communications 
-Remain in place 
-Waypoint selection 
-Unit operations 
Environment 

2D Terrain Model 
-Surface Configuration 
-Natural Features 
-Man-made Features 
Oceanographic Modeling 
-Contours with depth data 
External Forces 
-Wind 

-Sea State 

Measures of Performance 
Survivability 
Transit Times 
Cargo Transfer 
Resolution 

T-craft Levels (Single vs. Multiple) 
Architectural Design 

Interoperability Standards & Protocol 
Federate Capable 
High Level Architecture (HLA) 

Capable 

Reusable Program 
Program History 
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Program Considerations 
Open Source Code 
Input Operational Data 
-Object Library 
Auto Save / Auto Recover 
Stochastic Process 
Scriptable 

Discrete-Event/Time-Step 

Random Variables/Markov Principles 
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Scalability 


Variation 

Adjust abilities 
Systems 

Multiple Attributes 
Model Basic Physics 
Refueling Capabilities 
Movement Parameters 
Mode Selection 
Clone / Copy Functions 
Military Operations 
-Guard 
-Patrol 
-Orbit 
-Attack 
-Flee / Run 
-Defend 

-Grouping Functions 
-Inter Communications 
-Remain in place 
-Waypoint selection 
-Unit operations 
Environment 

2D Terrain Modeling 

-Surface Configuration 
-Natural Features 
-Man-made Features 
Oceanographic Modeling 
-Contours with depth data 
External Forces 
-Wind 

-Sea State 

Measures of Performance 
Survivability 
Transit Times 
Cargo Transfer 
Resolution 
Force Levels 

T-craft Levels (Single vs. Multiple) 
Adjudication 
Attain abilities 
Results 

Units of Measure 
MOP Translations 
User Defined Data Output 
Battle Damage Assessments 
Engagement 

Probability Tables Ph/Pk 
Sensor Algorithms Integration 
Weapons Algorithms Integration 
Indirect Fire Capabilities 
Sensor Detections 
Battle Damage 
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APPENDIX B. SIMKIT SOURCE CODE FOR SBE SCENARIO 


/* * 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* MainProgram Class 
*/ 


package TCraftSourceCode; 


import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 


j ava.awt.geom.Point2D; 

j ava.beans.PropertyChangeListener; 

j ava.io.BufferedWriter; 

j ava.io.FileNotFoundException; 

j ava.io.FileWriter; 

j ava.io.IOException; 

j ava.lang.reflect.Array; 

j ava.util.ArrayList; 

j ava.util.LinkedList; 

simkit.random.RandomVariate; 

simkit.random.RandomVariateFactory; 

simkit.smd.BasicLinearMover; 

simkit.smd.BasicSensor; 

simkit.smd.CookieCutterSensor; 

simkit.smd.RandomMoverManager; 

simkit.smd.SensorMoverReferee; 

simkit.smdx.WayPoint; 

simkit.stat.SimpleStatsTimeVarying; 

simkit.Schedule; 

simkit.util.SimplePropertyDumper; 


public class MainProgram { 

/** 

* @param Main program execution file 
*/ 

public static void main(String[] args) { 


//Friendly force setup with speed set to 40 
TCraft friend = new TCraft("TCraft," 40.0); 


/* 

* Friendly way point inputs 

* TCraft starts @ Debarkation point (DBK) and is loaded. 

* TCraft transits to SeaBase Operations (SBO) area to check damage 
and cargo load. 

* TCraft then transits to Shore landing site (SHO) to unload cargo. 

* TCraft completes Shore Cargo requirements and returns to DBK. 

* 

* DBK => SBO => SHO ===> Complete cargo tranfer requirements => DBK 
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/ 


LinkedList<WayPoint> wayPointList = new LinkedList<WayPoint>() ; 

//Adds waypoints to link list for Mover Manager inputs at start time 

wayPointList.add(TCraft.DBK) ; 

wayPointList.add(TCraft.SBO) ; 

wayPointList.add(TCraft.SHO) ; 

wayPointList.add(TCraft.SBO); 

wayPointList.add(TCraft.SHO); 

wayPointList.add(TCraft.SBO) ; 

wayPointList.add(TCraft.SHO) ; 

wayPointList.add(TCraft.SBO) ; 

wayPointList.add(TCraft.DBK); 

TCraftMoverManager friendMM = new TCraftMoverManager(friend, 
wayPointList, true); 

//Adding listeners 

friend.addSimEventListener(friendMM); 
friendMM.addSimEventListener(friend); 

//Enemy force setup 

BasicLinearMover enemy = new BasicLinearMover("Enemy," new 
Point2D.Double(5.0, 10.0), 10.0); 

RandomVariate[] rv = new RandomVariate[2]; 

rv[0] = RandomVariateFactory.getlnstance("Uniform ," -20.0, 20.0) 
rv[1] = RandomVariateFactory.getlnstance("Normal," 0.0, 5.0); 

RandomMoverManager randomMoverManager = new RandomMoverManager(enemy 
rv, true); 

BasicSensor enemyEye = new CookieCutterSensor(enemy, 10.0); 

//Sea base setup 

BasicLinearMover seabase = new BasicLinearMover("Seabase ," new 
Point2D.Double(0.0, 0.0), 0.0); 

BasicSensor seabaseEye = new CookieCutterSensor(seabase, 15.0); 

//Print of objects in simulation to check initialization 
//System.out.println(friend); 

//System.out.println(friendMM); 

//System.out.println(enemy); 

//System.out.println(randomMoverManager); 

//System.out.println(enemyEye); 

//System.out.println(seabase) ; 

//System.out.println(seabaseEye) ; 

//Referee setup 

SensorMoverReferee referee = new SensorMoverReferee(); 

friend.addSimEventListener(referee); 

friendMM.addSimEventListener(referee) ; 

enemy.addSimEventListener(referee); 

enemyEye.addSimEventListener(referee) ; 

seabase.addSimEventListener(referee); 

seabaseEye.addSimEventListener(referee) ; 
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//Mediator setup 

TCraftMediator tCraftMediator = new TCraftMediator(); 
referee.addMediator(CookieCutterSensor.class, TCraft.class, 
tCraftMediator); 

//Sensor setup 

HostileSensor hostileSensor = new HostileSensor(); 
enemyEye.addSimEventListener(hostileSensor); 

//Adjudicator setup 

Adjudicator adjudicator = new Adjudicator(); 

hostileSensor.addSimEventListener(adjudicator) ; 

//Property dumper setup 

//SimplePropertyDumper simplePropertyDumper = new 
SimplePropertyDumper(); 

//friend.addPropertyChangeListener(simplePropertyDumper); 

//Statistic listener setup 
PropertyChangeListener cargoAmount = new 
SimpleStatsTimeVarying("cargo"); 
friend.addPropertyChangeListener(cargoAmount); 
PropertyChangeListener damageAmount = new 
SimpleStatsTimeVarying("damage"); 
friend.addPropertyChangeListener(damageAmount); 
PropertyChangeListener shoreCargoAmount = new 
SimpleStatsTimeVarying("shoreCargo") ; 
friend.addPropertyChangeListener(shoreCargoAmount); 
PropertyChangeListener surv = new 

SimpleStatsTimeVarying("survivability"); 
friend.addPropertyChangeListener(surv); 

PropertyChangeListener msnFlag = new 

SimpleStatsTimeVarying("missionFlag"); 
friend.addPropertyChangeListener(msnFlag); 

//Simulation initial scheduling commands 
Schedule.setEventSourceVerbose(true) ; 

Schedule.stopAtTime(50.0) ; 

Schedule.setVerbose(false) ; 

//sets the number of iterations/replications the simulation will 
conduct 

int iteration = 1; 

//Declares arraye to store data points 
doublet] sc = new double [iteration]; 
int[] sv = new int [iteration]; 
doublet] mt = new double [iteration]; 

//Handles the replication of the simulation 
for (int i = 0; i < iteration; i++) { 

Schedule.reset (); 

Schedule.startSimulation(); 
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System.out.println(friend.getShoreCargo() + " " + 

friend.getSurvivability() + " " + friend.getMissionTime()); 

//Stores data values at completion of each replication 
sc[i] = friend.getShoreCargo (); 
sv[i] = friend.getSurvivability() ; 
mt[i] = friend.getMissionTime() ; 


//Handles writing values stored in array to designated file 
BufferedWriter bufferedWriter = null; 

try { 

//Declares BufferedWriter object 

buf feredWriter = new Buf feredWriter (new FileWriterCFileName.txt")) 
for (int i = 0; i < iteration; i++){ 

//Start writing to the output stream 

bufferedWriter.write(sc[i] + " " + sv[i] + " " + mt[i]); 

bufferedWriter.newLine() ; 

} 

} catch (Exception e) { 
e.printStackTrace() ; 

} finally { 

//Closes BufferedWriter 
try { 

if (bufferedWriter != null) { 
bufferedWriter.flush() ; 
bufferedWriter.close() ; 

} 

} catch (IOException e) { 
e.printStackTrace() ; 

} 

} 

System, out.println("Complete!") ; 


} 


} 
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/** 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* TCraft Class 
*/ 

package TCraftSourceCode; 

import java.awt.geom.Point2D; 
import simkit.Schedule; 
import simkit.random.RandomVariate; 
import simkit.random.RandomVariateFactory; 
import simkit.smd.BasicLinearMover; 
import simkit.smdx.WayPoint; 


public class TCraft extends BasicLinearMover { 

/* 

* State Variables 
*/ 

//monitors cargo carried on TCraft 
protected double cargo; 

//monitors damage to TCraft 
protected double damage; 

//monitors the amount of cargo received at the shore 
protected double shoreCargo; 

//monitors the survivability rate. Takes values 0 (not survive) and 1 
(survive) 

protected int survivability; 

//monitors the status of the mission. Takes values 0 (not complete) 
and 1 (complete) 

protected int missionFlag; 

//monitors mission time 
protected double missionTime; 

//coordinates for all possible destinations for TCraft 
protected static final WayPoint DBK = new WayPoint(new 
Point2D.Double(-20.0, 20.0), 40.0); 

protected static final WayPoint SBO = new WayPoint(new 
Point2D.Double(0.0, 0.0), 40.0); 

protected static final WayPoint SHO = new WayPoint(new 
Point2D.Double(20.0, -20.0), 40.0); 

//cargo threshold for shore 

protected static final double SHORE_CARGO_THRESHOLD = 1000.00; 
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//TCraft Mover Manager variable 
public TCraftMoverManager friendMM; 

//Declaration of TCraft Waypoint variable 
public WayPoint destination; 

//Declaration of Random Variate variable for times 
public RandomVariate repairTime = 

RandomVariateFactory.getInstance("Exponential15); 

public RandomVariate loadTime = 

RandomVariateFactory.getlnstance("Exponential," 10); 

public RandomVariate unloadTime = 

RandomVariateFactory.getlnstance("Exponential20) ; 

//Declaration of Random Variate 
public RandomVariate cargoLoadedLow; 

//Declaration of Random Variate 
public RandomVariate cargoLoadedHigh; 

//Declaration of Random Variate 
public RandomVariate number; 

/* 

* Parameters 
*/ 

// Threshold of damage recieved for TCraft to be killed 
public double damageThreshold = 0.8; 

// Threshold of damage recieved for TCraft to be repaired 
public double repairThreshold = 0.4; 

/** 

* Constructor 

* 

* We assume that every new TCraft is initially located at the 

* debarkation point (DBK) 

* 

* @param name, the name of the TCraft 

* speed, the speed of the TCraft 
*/ 

public TCraft(String name, double speed) { 
super(name, DBK.getPoint(), speed); 

} 

/** 

* Getter method for cargo 
*/ 

public double getCargoO { 
return cargo; 

} 

/** 
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* Getter method for damage 
*/ 

public double getDamageO { 
return damage; 

} 

/** 

* Getter method for shoreCargo 
*/ 

public double getShoreCargo() { 

return shoreCargo; 

} 

/** 

* Getter method for survivability 
*/ 

public int getSurvivability() { 

return survivability; 

} 

/** 

* Getter method for mission flag 
*/ 

public int getMissionFlag() { 

return missionFlag; 

} 

/** 

* Getter method for mission time 
*/ 

public double getMissionTime() { 

return missionTime; 

} 

/** 

* Repair Function 

* 

* @param mover, the TCraft to be repaired 

* All Cargo will be lost during the repair process 

* and Damage will be reset to 0.0. 

*/ 

public void doRepair (TCraft mover) { 

//Resetting Cargo 

double oldcargo = mover.getCargo() ; 
cargo = 0.0; 

firePropertyChange("cargo ," oldcargo, mover.getCargo()); 
//Resetting Damage 

double olddamage = mover.getDamage(); 
damage = 0.0; 

firePropertyChange("damage ," olddamage, mover.getDamage()) 
waitDelay("Load," 0.0, mover); 

} 
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/** 

* Load Function 

* 

* @param mover, the TCraft to be loaded 

* Cargo will be loaded at DBK to initialize 

* the TCraft with a random amount of cargo. 
*/ 

public void doLoad (TCraft mover) { 


//Generation of random cargo amounts in one three distributions at 

DBK 

//cargoLoadedLow = RandomVariateFactory.getlnstance("Uniform ," 0, 

750); 

//cargoLoadedLow = RandomVariateFactory.getlnstance("Normal ," 525, 

200 ) ; 

cargoLoadedLow = RandomVariateFactory.getlnstance("Exponential ," 

300) ; 


//Finds a random number in the distribution 
for(int i = 0; i < Math.random()*Math.random(); i++){ 
cargoLoadedLow.generate(); 

} 


//Generation of random cargo amounts in one three distributions at 

SBO 

//cargoLoadedHigh = RandomVariateFactory.getlnstance("Uniform ," 

300, 750); 

//cargoLoadedHigh = RandomVariateFactory.getlnstance("Normal ," 525, 

200 ) ; 

cargoLoadedHigh = RandomVariateFactory.getlnstance("Exponential ," 

300) ; 


//Finds a random number in the distribution 
for(int i = 0; i < Math.random()*Math.random(); i++){ 
cargoLoadedHigh.generate(); 

} 

//Loading TCraft 

if (mover.getCurrentLocation().equals(DBK.getPoint())) { 

//Pulling the next random number from the generator 
double numericCargo = cargoLoadedLow.generate(); 

//Updating cargo amounts 
double old = mover.getCargo(); 
cargo = cargo + numericCargo; 

firePropertyChange("cargo ," old, mover.getCargo()); 

} else if (mover.getCurrentLocation().equals(SBO.getPoint()) && 

( ! (missionFlag == 1))) { 

//Pulling the next random number from generator 
double numericCargo = cargoLoadedHigh.generate(); 
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//Updating cargo amounts 
double old = getCargo(); 
cargo = cargo + numericCargo; 

firePropertyChange("cargo," old, mover.getCargo()); 

} 


/** 

* Unload Function 

* 

* @param mover, the TCraft to be unloaded 
*/ 

public void doUnload (TCraft mover) { 

//Updating cargo amounts 
double old = mover.getCargo() ; 
double oldSC = mover.getShoreCargo() ; 
shoreCargo = (shoreCargo + old); 
cargo = 0.0; 

firePropertyChange("shoreCargo," oldSC, (mover.getShoreCargo())); 
firePropertyChange("cargo ," old, mover.getCargo()); 

//Handles conditions when shore cargo requirement is complete 
if (mover.getShoreCargo() >= SHORE_CARGO_THRESHOLD) { 

//Updating mission status 

int oldm = mover.getMissionFlag(); 

missionFlag = 1; 

firePropertyChange("missionFlag ," oldm, mover.getMissionFlag()); 

} 

waitDelay("MoveTo ," unloadTime, mover); 

} 

/** 

* End of Service Function 
*/ 

public void doEndService(TCraft mover) { 

//Store time in system 

double oldTime = mover.getMissionTime(); 

//Updating mission time of TCraft 

double timelnSystem = Schedule.getSimTime(); 

missionTime = timelnSystem; 

firePropertyChange("missionTime ," oldTime, mover.getMissionTime()) 


//Updating survivability rate of TCraft 
int oldSurv = mover.getSurvivability(); 
survivability = 1; 

firePropertyChange("survivability ," oldSurv, 
mover.getSurvivability() ) ; 

} 
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/** 

* Reset Function 
*/ 

public void reset () { 


super.reset (); 
cargo = 0.0; 
damage = 0.0; 
survivability = 1; 
shoreCargo = 0.0; 
missionFlag = 0; 
missionTime = 0.0; 


public void doRun(TCraft mover) { 

firePropertyChange("cargo," mover.getCargo()); 
firePropertyChange("damage," getDamage()); 
firePropertyChange("survivability ," getSurvivability()) 
firePropertyChange("shoreCargo ," getShoreCargo()); 
firePropertyChange("missionFlag ," getMissionFlag()); 

} 

} 
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/** 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* TCraftMoverManager Class 
*/ 

package TCraftSourceCode; 

import java.awt.geom.Point2D; 
import java.util.LinkedList; 
import java.util.Listlterator; 

import simkit.Schedule; 

import simkit.SimEntityBase; 

import simkit.random.RandomVariate; 

import simkit.random.RandomVariateFactory; 

import simkit.smd.Mover; 

import simkit.smdx.WayPoint; 

public class TCraftMoverManager extends SimEntityBase { 

/** 

* List of desired WayPoints the Mover is to traverse 
*/ 

private LinkedList<WayPoint> wayPoint; 

/** 

* Points to next WayPoint if hasNextO is true. 

*/ 

protected ListIterator<WayPoint> nextWayPointlter; 

/** 

* If true, then start Mover from Run event 
*/ 

private boolean startOnRun; 

/** 

* The one Mover this instance is managing 
*/ 

private Mover mover; 

/** 

* Instantiate a PathMoverManager with the given Mover, WayPoints, 

* and whether to start immediately or wait. 

* @param mover My Mover 

* @param waypoint List of WayPoints to traverse 

* @param startOnRun If true, start from Run event 
*/ 

public TCraftMoverManager(TCraft mover, 

LinkedList<WayPoint> waypoint, boolean startOnRun) { 
setMover(mover); 
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setWaypoint(waypoint) ; 
setStartOnRun(startOnRun) ; 


/** 

* Set nextWayPointlter to beginning of waypoint 
*/ 

public void reset () { 

super.reset (); 

nextWayPointlter = wayPoint.listlterator (); 


/** 

* If startOnRun is true, schedule Start. 

*/ 

public void doRun() { 

if (isStartOnRun()) { 

waitDelay("Start," 0.0); 

} 

} 

/** 

* If there is a WayPoint, schedule StartMove(d, s), where d is the 

* location and s is the speed specified by the WayPoint objst. 

*/ 

public void doStartO { 

nextWayPointlter = wayPoint.listlterator(); 

WayPoint next = nextWayPointlter.hasNext() ? 

nextWayPointlter.next () : null; 

firePropertyChange("nextWayPoint ," next); 

if (next != null) { 

waitDelay("MoveTo," 0.0, next.getPoint(), next.getSpeed()); 

} 


/** 

* Empty - to be heard. 

* @param destination desired destination 

* @param speed desired speed 
*/ 

public void doMoveTo(Point2D destination, double speed) { 

} 

/** 

* Heard from mover. If there is another WayPoint, schedule 

* MoveTo (d,s) for it; otherwise, schedule OrderStop(mover). 

* @param mover My mover 
*/ 

public void doEndMove(TCraft mover) { 

RandomVariate moveTime = 

RandomVariateFactory.getlnstance("Exponential ," 1); 

WayPoint next = nextWayPointlter.hasNext () ? 

nextWayPointlter.next() : null; 
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firePropertyChange("nextWayPoint ," next); 
if (next != null) { 

//Handles status of TCraft and scheduling events 
if (mover.getCurrentLocation().equals(TCraft.SBO.getPoint()) && 
mover.getMissionFlag() == 0 && 

mover.getDamage() >= mover.repairThreshold) { 
waitDelay("Repair ," 0.0, mover); 

} 

if ((!mover.getCurrentLocation().equals(TCraft.SHO.getPoint())) && 

mover.getMissionFlag() == 0 && 
mover.getDamage() < mover.repairThreshold && 
mover.getCargo() <= 300) { 

waitDelay("Load ," 0.0, mover); 

} 

if (mover.getCurrentLocation().equals(TCraft.SHO.getPoint()) && 

mover.getMissionFlag() == 0) { 

waitDelay("Unload ," 0.0, mover); 

} 

waitDelay("MoveTo ," moveTime, next.getPoint(), next.getSpeed()); 

if ((!(mover.getCurrentLocation().equals(TCraft.DBK.getPoint()))) 
&& mover.getMissionFlag() == 1) { 

waitDelay("EndService ," 0.0, mover); 

} 

} 

if (next == null) { 

//Store time in system 

double oldTime = mover.getMissionTime(); 

//Updating mission time of TCraft 

double timelnSystem = Schedule.getSimTime(); 

mover.missionTime = timelnSystem; 

firePropertyChange("missionTime ," oldTime, mover.getMissionTime()) 

waitDelay("OrderStop ," 0.0, mover); 

} 


/** 

* Schedule OrderStop(mover). 

*/ 

public void doStopO { 

//System.out.printIn("OrderStop"); 
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waitDelay("OrderStop ," 0.0, mover); 

} 

/** 

* @return the list of WayPoints (shallow copy) 

*/ 

public LinkedList<WayPoint> getWaypoint() { 

return new LinkedList<WayPoint>(wayPoint); 

} 

/** 

* @param wayPoint the wayPoint to set 
*/ 

public void setWaypoint(LinkedList<WayPoint> waypoint) { 
this.wayPoint = new LinkedList<WayPoint>(waypoint); 

} 

/** 

* If true, start moving at beginning of simulation 

* @return the startOnRun 
*/ 

public boolean isStartOnRun() { 

return startOnRun; 

} 

/** 

* @param startOnRun the startOnRun to set 
*/ 

public void setStartOnRun(boolean startOnRun) { 
this.startOnRun = startOnRun; 

} 

/** 

* @return the mover 
*/ 

public Mover getMover() { 
return mover; 

} 

/** 

* @param mover the mover to set 
*/ 

public void setMover(TCraft mover) { 

if (this.mover != null) { 

this.mover.removeSimEventListener(this); 
this.removeSimEventListener(this.mover); 

} 

this.mover = mover; 

this.mover.addSimEventListener(this); 
this.addSimEventListener(this.mover); 

} 
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/** 

* @return the nextWayPointlter 
*/ 

public ListIterator<WayPoint> getNextWayPointlter() { 

return nextWayPointlter; 

} 

/** 

* @return next WayPoint or null if none 
*/ 

public WayPoint getNextWayPoint() { 

int index = nextWayPointlter.nextlndex(); 
if (index < wayPoint.size()) { 

return wayPoint.get(index); 

} else { 

return null; 

} 

} 

} 
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/** 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* TCraftMediator Class 
*/ 

package TCraftSourceCode; 

import simkit.SimEntityBase; 

import simkit.smd.CookieCutterSensor; 

import simkit.smd.SensorMoverMediator; 

/** 

* Simple Mediator. Schedules Detections and Undetections. 

* (Aversion $Id: CookieCutterMediator . j ava 

* @author Professor Arnold Buss @ NPS 
*/ 

public class TCraftMediator extends SimEntityBase implements 
SensorMoverMediatorkTCraft, CookieCutterSensor>{ 

/** 

* Schedule Detection(mover) on sensor with delay of 0.0 if the 

* sensor hasn't already detected the target. 

* @param mover The target 

* @param sensor The Sensor 
*/ 

public void doEnterRange(TCraft mover, CookieCutterSensor sensor) { 

if (!sensor.getContacts().contains(mover)) { 

sensor.waitDelay("Detection ," 0.0, mover); 

} 

} 

/** 

* Schedule Undetection(mover) with delay of 0.0. 

* @param mover The target 

* @param sensor The Sensor 
*/ 

public void doExitRange(TCraft mover, CookieCutterSensor sensor) { 
sensor.waitDelay("Undetection," 0.0, mover); 

} 
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/** 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* HostileSensor Class 
*/ 

package TCraftSourceCode; 
import simkit.SimEntityBase; 

public class HostileSensor extends SimEntityBase { 

public void doDetection(TCraft mover) { 

//When TCraft is detected, an Attack event is scheduled 
if (mover.getName() == "TCraft") { 
waitDelay("Attack ," 0.0, mover); 

} 

} 


} 
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/** 

* SBE Scenario 

* Simkit API Source code in Java 2 Platform Standard Ed. 5.0 

* Authors: LT Ryan Hernandez 

* LtCOL (HEA) Sotiris Papadopoulos 

* Date: May 2010 

* Adjudicator Class 
*/ 

package TCraftSourceCode; 
import simkit.Schedule; 


public class Adjudicator extends HostileSensor { 

public void doAttack(TCraft mover) { 
waitDelay("BDA," 0.0, mover); 

} 

public void doBDA(TCraft mover) { 

//generates random damage amount 
double damage = Math.random(); 

//Updating damage 

double old = mover.getDamage(); 

mover.damage = mover.damage + damage; 

firePropertyChange("damage ," old, mover.getDamage()); 
if (mover.damage > mover.damageThreshold) { 
waitDelay("Killed ," 0.0, mover); 

//Store time in system 

double oldTime = mover.getMissionTime(); 

//Updating mission time of TCraft 
double timelnSystem = Schedule.getSimTime(); 
mover.missionTime = timelnSystem; 
firePropertyChange("missionTime ," oldTime, 
mover.getMissionTime()); 

} 

} 

public void doKilled(TCraft mover) { 

//Updating survivability 
mover.survivability = 0; 

Schedule.stopSimulation(); 

} 

} 
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